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ABSTRACT 


As  DOD  increases  their  reliance  on  space  assets,  a  call  for  doing  more  for  less  has 
been  initiated.  Requests  for  more  capability  will  present  opportunities  in  technological 
advancements  including  methods  for  controlling  those  assets.  Constrained  by  a  reduced 
budget,  the  decision  maker  must  be  able  to  properly  evaluate  systems  and  select  the  best 
candidate.  For  Telemetry,  Tracking,  and  Commanding  (TT&C),  the  decision  maker 
needs  an  objective  methodology  capable  of  aiding  in  the  evaluation  of  TT&C  systems. 
The  thesis  provides  such  an  essential  tool  that  will  aid  in  the  assessment  of  proposed 
TT&C  architectures.  The  first  section  describes  the  process  of  TT&C  by  using  activity 
modeling  to  describe  the  key  functions  and  the  present  interrelationships  among  these  key 
functions.  To  provide  an  initial  basis  of  understanding,  three  current  TT&C  architectures 
were  discussed:  Air  Force  Satellite  Control  Network,  Mission  Control  Center  Johnson 
Space  Center,  and  Naval  Satellite  Operations  Center.  This  enabled  the  authors  to 
highlight  favorable  trends  utilized  for  enhancing  performance.  The  thesis  concludes  with 
a  demonstration  of  an  objective  methodology  based  on  the  Analytic  Hierarchy  Process. 
This  approach  resulted  in  the  ability  to  provide  a  weighted  ranking  of  proposed  TT&C 
architectures  and  was  illustrated  using  current  architectures. 
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1.  INTRODUCTION 


A.  PURPOSE  OF  THESIS 

The  purpose  of  this  thesis  is  to  present  the  decision  maker  with  an  objective 
methodology  that  can  be  used  in  determining  the  selection  of  a  most  favorable  Telemetry, 
Tracking,  and  Commanding  (TT&C)  architecture.  It  has  been  observed  that  a  need  exists 
to  integrate  the  current  satellite  control  network  in  order  to  achieve  a  higher  degree  of 
efficiency.  To  do  this,  the  decision  maker  requires  four  elements;  a  set  of  joint 
requirements,  a  system  architecture,  an  implementation  plan,  and  a  cost  operational 
effectiveness  analysis  (COEA).  Currently,  DOD  lacks  an  adequate  set  of  requirements, 
has  no  common  system  and  therefore  no  implementation  plan,  and  lastly  lacks  adequate 
information  to  put  together  an  effective  COEA.  This  thesis  emphasizes  identifying  a 
generic  TT&C  system  architecture  and  the  development  of  a  method  to  objectively 
compare  two  or  more  candidate  architectures  for  future  implementation. 

B.  METHODOLOGY 

In  order  to  better  understand  the  problems  associated  with  evaluating  Telemetry 
Tracking  and  Commanding  (TT&C)  architectures,  the  major  issues  that  effect  TT&C 
systems  will  be  discussed.  Then,  a  discussion  of  a  generic  TT&C  process  will  be 
examined  followed  by  a  description  of  three  well  known  existing  architectures,  the  Air 
Force  Satellite  Control  Network  (AFSCN),  Mission  Control  Center  (MCC),  and  Naval 
Satellite  Operations  Center  (NAVSOC).  Lastly,  an  objectively  based  scaling  criteria  is 
developed  and  presented  along  with  an  illustrated  example  using  the  AFSCN,  MCC,  and 
NAVSOC  architectures  to  better  clarify  the  concepts  of  the  methodology. 

C.  SCOPE  OF  THESIS 

The  main  focus  of  this  thesis  is  to  present  a  useful  methodology  for  evaluating 
current  and  future  TT&C  architectures.  A  general  discussion  of  issues  that  affect  these 
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architectures  will  be  given  to  characterize  the  environment.  The  thesis  will  only  address 
those  issues  that  affect  generic  TT&C  systems.  The  objective  methodology  is  presented 
along  with  an  illustration  using  the  AFSCN,  MCC,  and  NAVSOC  architectures  as  they 
exist  at  the  time  of  this  writing.  As  a  result  of  the  unavailability  of  actual  values,  all 
values  associated  with  the  illustration  are  chosen  for  illustrative  purposes  only. 

D.  BACKGROUND  AND  ISSUES  SURROUNDING  TT&C 

Before  proceeding,  it  is  important  that  the  reader  have  an  understanding  of  the 
studies  and  publications  currently  effecting  DOD  Space  agencies  and  TT&C  architectural 
development.  This  brief  background  will  provide  the  foundation  for  the  rest  of  the 
material  presented  in  this  thesis. 

1.  Future  Integrated  TT&C  Architecture  Study 

a.  History 

Early  in  1993,  Congress  viewed  satellite  control  as  too  costly  and  in  January  of 
1994,  the  Joint  Staff/J6  directed  the  United  States  Space  Command  (USSPACECOM)  to 
lead  in  the  development  of  the  Future  Integrated  TT&C  Architecture  Study  (FU  AS). 
About  the  same  time,  the  General  Accounting  Office  (GAO)  requested  the  use  of  the 
PITAS  to  aid  in  the  evaluation  of  the  Fiscal  Year  (FY)  96  Appropriations. 

b.  Purpose 

Originally  USSPACECOM  was  directed  to  do  the  following:  (1)  develop  a 
comprehensive  architecture  and  roadmap  for  an  integrated  DOD  satellite  control 
infrastructure;  and,  (2)  reassess  the  Office  of  the  Secretary  of  Defense  (OSD)  policy  for 
application  of  MIL-STD-1582C,  Satellite  Data  Link  Standard:  Uplinks  and  Downlinks. 
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However,  in  a  counter  proposal  accepted  by  the  Director  Joint  Staff,  USSPACECOM 
opted  to  emphasize  interagency  ties  first,  then  to  address  high  level  system  features  with 
the  increased  economy  of  making  resources  accessible  for  sharing  across  all  participating 
agencies  as  a  goal.  [Ref.  1] 

In  order  to  accomplish  this  task  five  panels  were  organized  and  supervised  by  a 
Senior  Steering  Group  (SSG).  Each  of  the  panels  addressed  one  of  the  following: 
Requirements,  Current  Status,  Evaluation  Criteria,  Fusion,  and  Implementation. 

c.  Summary  of  Findings 

Findings  from  the  FITAS  revealed  several  factors,  some  of  which  will  be 
discussed  here.  It  was  determined  that  the  existence  of  a  central  authority  to  develop 
interagency  satellite  control  guidelines  was  not  readily  accessible.  The  lack  of  mutual 
interagency  interaction  and  a  means  to  establish  satellite  control  changes  across  the 
organizations  needs  to  be  examined.  In  a  related  issue,  it  was  determined  that 
organizations  have  evolved  their  own  set  of  requirements  and  that  benefits  may  lie  in  the 
development  of  universal  requirements.  The  complexity  of  the  Air  Force  Satellite 
Control  Network  (AFSCN)  software  maintenance  program  and  their  manpower  intensive 
approach  to  satellite  control  was  also  addressed.  For  a  complete  discussion  on  the  FITAS 
findings  see  Reference  1.  [Ref  1] 
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d.  Conclusions 


The  completion  of  the  PITAS  touched  on  ten  key  concepts  which  involved  the 
development  of  a  long-term  integrated  DOD  satellite  control  architecture  and  increased 
interagency  satellite  resource  sharing.  The  ten  concepts  discussed  are:  (1)  Management 
Structure,  (2)  First  Plug-N-Use  Tier,  (3)  Second  Plug-N-Use  Tier,  (4)  S-Band  Exclusive 
Use  of  the  Second  Plug-N-Use  Tier,  (5)  Use  of  In-Band  commanding,  (6)  Frequency 
allocation  issues,  (7)  Wave  form  or  frequency  changes,  (8)  AFSCN  transition  to 
distributed  processing,  (9)  Manning  reductions,  (10)  MIL-STD-1582C.  The  authors  have 
decided  to  present  those  concepts  most  pertinent  to  the  development  of  this  thesis. 

(1)  First  Plug-N-Use  Tier:  An  initial  overall  effort  to  make  conunon  TT&C 
functions  of  individual  systems  accessible.  The  first  tier  is  intended  to  penrnt  all  Defense 
Satellite  Control  Network  (DSCN)  nodes  to  produce  and  receive  mutually  understandable 
and  useful  information  for  all  DSCN  services.  [Ref.  1  ] 

(2)  Second  Plug-N-Use  Tier:  Intended  for  TT&C  and  mission  data 
operations  that  will  need  to  plug  into  the  evolving  Defense  or  National  Information 
Infrastructure  (Nil)  wherever  possible  for  economy  of  scale  and  access  to  all  other  DSCN 
nodes.  New  systems  ,  and  those  undergoing  upgrades,  will  be  required  to  conform 
immediately.  International  commercial  standards  will  be  used  to  the  maximum  extent 
possible.  [Ref.  1] 
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(3)  AFSCN  transition  to  distributed  processing.  The  AFSCN  must 
transition  to  object  oriented,  distributed  processing.  To  capitalize  on  reduced  software 
development  costs  and  software  that  already  exists  or  is  being  developed  for  TT&C, 
communications,  scheduling,  and  so  on.  [Ref.  1] 

(4)  Manning  reductions.  Reduction  in  On-Console,  Communication,  and 
Real-time  Engineering  Support.  On  console  manning  could  be  reduced  by  up  to  33%. 
Conununication  manning  could  be  reduced  by  up  to  45%.  Real-time  engineering  support 
for  trend  monitoring  and  anomaly  resolution  could  also  be  greatly  reduced.  [Ref.  1] 

2.  Objective  Technical  Architecture  Overview 
a.  History 

The  Objective  Technical  Architecture  (OTA)  was  established  to  ensure  both  the 
North  American  Defense  Command  (NORAD)  and  USSPACECOM  remain  a  viable 
force  structure.  The  operational  requirements  document  (ORD)  was  designed  to  provide 
the  needed  guidance  in  the  acquisition  of  advanced  technology  and  infuse  that 
technology  into  NORAD  and  USSPACECOM  Integrated  Command  and  Control  System. 

By  definition  the  OTA  describes  a  minimal  set  of  rules  governing  the 
arrangement,  interaction,  and  interdependence  of  the  parts  or  elements  that  together  may 
be  used  to  form  an  information  system,  and  whose  purpose  is  to  ensure  that  a  conformant 
system  satisfies  a  specified  set  of  requirements.  [Ref.  2] 
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The  OTA  is  divided  into  five  sections;  (1)  purpose,  background,  and  scope;  (2) 
the  Elements  of  NORAD  /  USSPACECOM  OTA  and  infrastructure;  (3)  identification  of 
a  set  of  standards  guidance  profiles  based  on  OTA  -  Technical  Reference  Model  (OTA 
TRM);  (4)  explanation  of  the  management  approach  for  the  OTA;  (5)  examples  of  how 
to  use  the  OTA  within  the  acquisition  of  information  systems.  [Ref  2] 

b.  Purpose 

The  OTA  is  designed  to  provide  guidance  while  defining,  designing,  and 
developing  those  systems  that  will  become  a  part  of  NORAD  and  USSPACECOM 
Integrated  Command  and  Control  System.  In  addition,  the  OTA  provides  guidance  to 
agencies  and  staffs  that  are  involved  in  the  directing  and  managing  modifications  of 
existing  NORAD  /  USSPACECOM  systems.  Lastly,  the  OTA  guides  those  involved  in 
the  testing,  integrating,  certifying,  and  training  or  maintaining  new  systems  or  modified 
systems.  [  Ref.  2] 

It  should  be  noted  that  the  OTA  applies  to  NORAD,  USSPACECOM,  Air  Force 
Space  Command  (AFSPC),  United  States  Army  Space  Command  (USARSPACE),  Naval 
Space  Command  (NAVSPACECOM),  Canada,  and  the  United  Kingdom.  While  the 
guidance  contained  within  the  OTA  applies  to  all  those  involved  in  requirements 
definition  and  analysis.  [  Ref.  2] 
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c.  Summary  of  Findings 


For  the  purpose  of  this  thesis,  the  authors  will  summarize  sections  two  and  three 
which  covers  both  elements  and  standards.  The  Command,  Control,  Communications, 
Computer  and  Intelligence  for  the  Warrior  (C4IFTW)  tenants  provide  the  bases  for  the 
OTA  operating  perspective.  The  eight  tenants  of  C41F1W  are  expounded  on  within  the 
OTA  and  are  listed  here  for  simplicity;  100  %  interoperability.  Common  Operating 
Environment  (COE),  Flexible  modular  C4I  packages,  Horizontal  and  vertical  C2,  CENC 
pull  on  demand.  Real  -  time  decision  aiding.  Global  resource  management  and  control, 
and  Seamless  operations. 

Along  with  the  above  tenants,  the  OTA  emphasizes  a  set  of  design  and 
development  principles  that  aid  in  broadening  the  development  of  mission  requirements 
that  include  configuration  management,  testing  and  certification,  training  and  simulation, 
security,  reliability,  maintainability,  robustness,  business  processes  and  data 
standardization. 

Consistent  with  the  direction  from  the  William  Perry  letter.  Specifications  & 
Standards  —  A  New  Way  of  Doing  Business,  dated  29  June  1994,  the  OTA  standards 
guidance  reflects  the  standards  currently  used  in  existing  operational  systems  and  /  or 
systems  currently  being  developed.  [Ref.  2] 

The  OTA  standards  guidance  stresses  the  importance  of  migrating  to  open 
systems  and  provides  four  types  of  performance-based  criteria;  commercial  item 
descriptions  (CIDs),  guide  specifications,  standard  performance  specifications,  and 
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program  peculiar  specifications.  These  specifications  would  develop  into  standards  for 
use  in  future  systems.  The  criteria  to  achieve  this  appears  throughout  the  OTA  guidance 
profiles.  [Ref.  2] 

3.  DOD  Technical  Architecture  Framework  for  Information  Management 

a.  History 

The  Technical  Architecture  Framework  for  Information  Management  (TAFIM) 
provides  guidance  necessary  to  establish  a  DOD  wide  framework  required  to  manage 
multiple  technical  architecture  initiatives.  The  TAFIM  is  intended  to  influence  three 
areas:  the  use  of  common  principles,  assumptions,  terminology  in  DOD  Component 
(Services,  Agencies,  and  CINCs)  technical  architectures;  the  definition  of  a  single 
structure  for  the  DOD  technical  infrastructure  components  (system  components)  and  how 
they  are  managed;  and  the  development  of  information  systems  in  accordance  with 
common  principles  to  permit  DOD  wide  integration  and  interoperability.  [Ref.  3] 

b.  Purpose 

The  TAFIM  provides  guidance  for  the  evolution  of  the  DOD  technical 
infrastmcture  by  focusing  on  the  following:  services,  standards,  design  concepts, 
components  and  configurations.  These  elements  guide  the  development  of  technical 
architectures  to  meet  specific  mission  requirements.  It  should  be  pointed  out  that  the 
TAFIM  does  not  provide  a  specific  system  architecture.  [Ref.  3] 
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Important  to  architecture  design,  the  TAFIM  introduces  concepts  such  as 
interoperability,  portability,  and  scalability  of  DOD  information  systems.  The  TAFIM 
assumes  that  information  systems  will  and  must  interoperate  at  some  time.  [Ref.  3] 

With  proper  implementation,  the  TAFIM  guidance  should  achieve  the  following 
results:  promote  integration,  interoperability,  modularity,  and  flexibility;  guide 
acquisition  and  reuse;  and  speed  delivery  of  information  technology  and  lower  its  costs. 
[Ref.  3] 

The  TAFIM  is  divided  into  eight  volumes  that  represent  the  varying  states  of 
development  and  maturity:  (1)  Overview,  (2)  Technical  Reference  Model,  (3) 
Architecture  Concepts  and  Design  Guidance,  (4)  Implementation  Manual,  (5)  Support 
Plan,  (6)  DOD  Goal  Security  Architecture,  (7)  Standards  Profile  and  Implementation 
Guidance,  and  (8)  DOD  Human  Computer  Interface  (HCI)  Style  Guide.  [Ref.  3] 

Of  particular  importance  to  this  thesis  is  Volume  3,  Architecture  Concepts  and 
Design  Guidance.  Volume  3  provides  concepts  and  design  guidance  that  will  help 
architects,  integrators,  and  system  designers  to  develop  information  systems  technical 
architectures  and  are  considered  in  the  context  of  the  Technical  Reference  Model  found  in 
Volume  2.  The  key  elements  found  in  this  volume  are  in  the  following  section.  [Ref.  4] 

c.  Summary  of  Findings 

Volume  3  of  the  TAFIM  series  describes  several  models  in  varying  degrees  of 
detail.  These  models  include:  the  Architecture  Models,  Client  /  Server  Models, 
Host-Based  Models,  Master-Slave  and  Three-Tiered  Models,  Peer-to-Peer  Models, 
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Distributed  Object  Management  Models,  Database  Management  Systems  (DBMS)  and 
Data  Models.  [Ref.  4] 

The  volume  also  defines  several  key  elements  involved  in  developing 
information  architectures  such  as  Data  Security.  Data  security  includes  measures  that  are 
implemented  to  prevent  unauthorized  access,  modification,  use,  and  dissemination  of  data 
stored  or  processed  by  a  computer  system.  Data  security  also  includes  data  integrity,  and 

protecting  the  system  from  physical  harm. 

The  Open  System  Interconnection  (OSI)  Reference  Model  is  used  for  data 
communications  in  the  TAFIM.  The  model  consists  of  the  following  seven  layers:  (1) 
physical  layer,  (2)  data  link,  (3)  network,  (4)  transport,  (5)  session,  (6)  presentation,  and 
(7)  application.  The  seven  layers  are  structured  to  facilitate  independent  development 
within  each  layer  and  to  provide  for  changes  independent  of  other  layers.  [Ref.  4] 

Lastly,  the  volume  provides  an  overall  Design  Guidance  for  use  by  all 
developers  of  information  systems.  The  following  are  guidelines  for  designing  specific 
architectures; 

•  An  architecture  will  contain  components  to  implement  only  those  reference 
model  services  that  it  requires.  [Ref.  4] 

•  Components  may  implement  one,  more  than  one,  or  only  part  of  a  service 
identified  in  the  reference  model.  [Ref.  4] 


10 


•  The  components  should  conform  to  the  profile  standards  that  are  relevant  to  the 
services  they  do  implement.  [Ref.  4] 

E.  OUTLINE  OF  CHAPTERS 

1.  Chapter  H.  Defining  the  Core  TT&C  Elements 

In  this  chapter,  a  description  of  a  generic  TT&C  system  is  provided  to  aid  the 
decision  maker  in  understanding  the  process  involved.  To  achieve  this,  the  most  basic 
elements  in  the  area  of  telemetry,  tracking,  and  commanding  are  defined.  A  discussion 
on  the  primary  functions  and  their  relationship  between  one  another  is  conducted.  The 
relationships  identified  in  the  TT&C  process  are  further  illustrated  through  graphic 
modeling. 

2.  Chapter  III.  Current  Methods  and  Trends 

In  this  chapter,  the  authors  present  a  background  on  three  well  known  U.S.  TT&C 
facilities  utilized  by  the  DOD:  Air  Force  Satellite  Control  Network  (AFSCN),  Mission 
Control  Center  (MCC),  and  the  Naval  Satellite  Operations  Center  (NAVSOC).  The 
background  includes  a  look  at  the  historical  development,  command  structure,  personnel, 
and  operational  methodology  used  by  each  facility.  The  trends  in  TT&C  architectures  are 
then  highlighted  and  are  used  as  an  aid  in  the  formulation  of  the  comparison 
methodology. 

3.  Chapter  IV.  Comparison  Methodology 

In  this  chapter,  the  actual  technique  for  comparison  is  presented.  The  process 
presented  is  an  objective  approach  that  is  intended  to  be  a  useful  step  by  step 
methodology  that  will  produce  valuable  information  for  the  decision  maker  about  which 
candidate  architecture  should  be  selected  amongst  a  number  of  alternatives.  Each  step  is 
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illustrated  in  an  example  conducted  using  the  AFSCN,  MCC,  and  NAVSOC 
architectures. 

4.  Chapter  V.  Conclusions  and  Recommendations 

As  stated  in  its  title,  this  chapter  will  provide  a  summary  that  highlights  essential 
ideas  discussed  and  recommend  areas  of  further  study. 


12 


II.  DEFINING  THE  CORE  TT&C  ELEMENTS 


A.  INTRODUCTION 

Although  there  exist  numerous  sources  concerning  TT&C,  there  has  been  little  or 
no  work  done  in  attempting  to  analyze  the  process  of  conducting  TT&C.  The  primary 
reason  for  understanding  this  process  is  to  ensure  TT&C  is  conducted  as  effectively  and 
efficiently  as  possible.  Secondly,  it  will  provide  the  decision  makers  a  more  through 
understanding  of  this  process  to  enable  them  to  make  sound  judgmental  choices  in  the 
procurement  of  future  systems.  This  is  accomplished  by  providing  a  basic  definition  of 
TT&C,  identification  and  mapping  of  functional  areas,  and  lastly  the  identification  of 
common  system  drivers.  This  chapter  will  provide  the  above  aids  to  the  decision  maker 
and  will  be  used  in  subsequent  chapters  to  examine  the  overall  TT&C  process  and  its 
associated  measures  of  performances  (MOPs)  and  measures  of  effectiveness  (MOEs). 

B.  DESCRIPTION  OF  A  GENERIC  TT&C  ARCHITECTURE 

As  the  name  implies,  the  most  fundamental  functions  of  TT&C  are  telemetry, 
tracking,  and  commanding.  In  order  to  utilize  a  space  vehicle  (SV)  one  must  first  be  able 
to  locate  it  and  then  track  it.  Next,  one  must  be  able  to  conununicate  with  it  and 
command  the  SV  to  carry  out  its  functions.  Lastly,  one  must  be  able  to  obtain  data 
(telemetry)  from  the  SV. 

1.  Telemetry 

The  telemetry  of  a  SV  consists  of  measurements  taken  onboard  by  the  SV  sensors 
and  then  transmitted  to  either  a  ground  facility  or  spacebome  receiver.  The  two  basic 
types  of  telemetry  are  analog  or  digital.  The  most  common  forms  are: 

•  High-Level  Analog 

A  telemetry  channel  with  information  encoded  as  an  analog  voltage. 

These  are  active  analog  inputs  in  that  the  command  and  data  handling 

system  does  not  provide  measurement  excitation.  Data  handling 
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equipment  converts  this  information  to  digital  form. 

[Ref.  5] 

•  Low-Level  Analog 

A  telemetry  channel  with  information  encoded  as  an  analog  voltage.  The 
signal  range  is  such  that  amplification  is  needed  before  the  information  is 
encoded  into  digital  form.  [Ref.  5] 

•  Passive  Analog 

A  telemetry  channel  with  information  encoded  as  a  resistance.  The 
command  and  data  handling  system  supplies  a  constant  current  to  die 
resistive  sensor  and  encodes  the  resulting  IR  voltage  drop  into  a  digital 
word.  [Ref.  5] 

•  Bi-Level  (Discrete)  Input 

A  telemetry  channel  conveying  two  state  information  (such  as  on/off  or 
enable/disable).  Information  is  encoded  as  voltages,  but  may  be  encoded  as 
a  resistance  or  presence  or  absence  of  a  signal.  [Ref.  5] 

•  Serial  Telemetry  (Digital)  Interface 

A  3 -signal  interface  used  to  transfer  digital  data  from  an  external  source  to 
the  data  handling  equipment.  The  command  and  data  handling  system 
provides  a  shift  clock  and  an  interface  enable  signal  to  control  data 
transfer.  [Ref.  5] 

Telemetry  is  essential  because  it  establishes  a  communication  path  downlink  from 
the  SV  to  the  ground  station.  This  allows  the  ground  station  to  receive  health  and  status 
of  the  SV  which  would  include  some  of  the  following:  voltages,  currents,  and 
temperatures.  In  addition,  mission/payload  related  data  would  be  downlinked  to  the 
ground  station  to  be  later  processed  and  disseminated  to  the  user. 

2.  Tracking 

Space  vehicle  tracking  involves  locating  a  specific  SV  and  then  following  its 
movement  through  space  as  a  function  of  time.  The  position  of  the  SV  as  a  function  of 
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time  is  determined  by  the  use  of  the  following  measurements:  elevation,  azimuth,  range, 
and  range  rate.  Once  the  SV  is  acquired,  the  ground  station  can  then  point  the  receiving 
antenna  at  the  S V  to  receive  the  telemetry  data.  Once  the  ground  station  begins  to  receive 
the  telemetry,  most  antennas  will  automatically  track  the  acquired  SV  maintaining 
maximum  signal  strength.  [Ref.  6] 

3.  Commanding 

Commanding  is  the  method  of  controlling  the  SV  from  the  ground  while  in 
line-of-sight  of  a  ground  station.  SV  commanding  is  important  for  many  reasons. 
Commands  transmitted  to  a  satellite  turn  on  or  off  such  things  as  thrusters,  sensors, 
recorders,  etc.  SV  commands  may  also  accomplish  an  attitude  maneuver  or  an  orbital 
adjustment  maneuver. 

The  four  primary  methods  of  transmitting  commands  are  single,  block,  repetitive, 
and  timed-repetitive.  Single  command  is  the  transmission  of  a  single  command  word. 
Block  command  is  a  group  of  single  commands  represented  by  just  one  command 
number.  A  repetitive  command  is  a  single  or  block  command  that  a  ground  station 
retransmits  continuously  until  there  is  a  command  verification  or  a  selected  number  of 
transmission  attempts  have  been  reached.  The  timed-repetitive  command  is  the 
transmission  of  a  block  or  single  command  for  a  given  period  of  time  (it  is  the  least 
frequently  used  method).  [Ref.  6] 

4.  Ground  System  Basic  Elements 

The  ground  system  of  a  TT&C  architecture  can  be  described  using  eight  elements: 

•  Antenna  System 

This  includes  a  single  antenna  and  mount,  its  associated  actuators, 
consoles  and  servo  circuitry  that  control  the  antenna,  the  feeds  and 
transmission  lines  that  carry  the  radio  frequency  (RF)  signal  to  and  from 
the  equipment.  [Ref.  5] 
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•  Autotracking 

The  use  of  a  received  space  vehicle  signal  to  steer  the  antenna.  [Ref.  5] 


•  Receive  RF  Equipment 

The  equipment  required  to  accept  the  downlink  carrier  frequency  from  the 
antenna  system,  down-convert  it  to  intermediate  frequency,  and 
demodulate  it  to  a  base  band  signal  for  the  equipment  devoted  to  mission 
data  recovery  and  TT&C.  [Ref.  5] 

•  Transmit  RF  Equipment 

The  equipment  required  to  accept  tracking  and  command  signals  from  the 
ground  systems  TT&C  component  and  modulate  them  onto  the  RF  uplink 
which  it  also  generates.  [Ref.  5] 


•  Mission  Data  Recovery  Equipment 

Equipment  required  to  condition  the  mission  data  before  relaying  it  to  data 
users  and  ground  system  components.  [Ref.  5] 


•  Data  User  Interface 

Equipment  required  to  connect  the  mission  data  recovery  equipment  and 
the  data  user.  [Ref.  5] 

•  TT&C  Equipment 

Equipment  required  to  condition  and  distribute  received  telemetry  and 
tracking  signals.  Also  it  electrically  formats,  authenticates,  and  time-tags 
transmitted  command  and  tracking  signals.  [Ref.  5] 


•  Station  Control  Center 

This  center  is  given  the  responsibility  to  control  the  configuration  of,  and 
the  interconnections  between,  the  ground  station  components.  Operating 
under  instructions  from  the  ground  system’s  mission  control  center,  it 
keeps  the  ground  station  configured  to  support  mission  operations.  [Ref 

5] 
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•  Mission  Control  Center 

This  center  plans  and  operates  the  entire  space  mission,  including  the 
configuration  and  scheduling  of  resources  for  both  space  and  ground 
system.  It  computes  and  issues  information  needed  by  ground  system 
elements  and  data  users,  such  as  data  on  the  spacecraft's  orbit,  ground 
station  pass  times,  and  antenna  pointing  angles.  [Ref.  5] 

C.  IDENTIFICATION  OF  TT&C  FUNCTIONS 

1.  Introduction 

This  section  will  develop  a  common  description  of  TT&C  related  functions  and 
illustrate  their  interrelationship  within  the  TT&C  process.  To  accomplish  this,  a  three 
level  approach  is  used.  This  approach  classifies  a  function  into  one  of  three  levels: 
Primary,  Secondary,  and  Sub-Function.  To  explicate  this  approach,  the  DOD  descriptive 
language  IDEF„  is  used.  In  particular,  Design/IDEF  (version  3.5)  developed  by  Meta 
software  corporation  was  the  tool  selected.  It  will  be  noted  that  in  this  chapter  only  the 
analysis  and  design  diagrams  for  the  higher  level  activities  will  appear.  The  complete  set 
of  IDEFo  illustrations  developed  for  this  architecture,  with  all  inputs  and  outputs  included 
is  located  in  Appendix  A.  IDEF„  requires  the  user  to  define  the  functions  associated 
Input,  Output,  Control,  and  Mechanisms.  These  four  elements  will  be  highlighted  in  the 
following  sub-sections  j  and  a  complete  definition  of  the  elements  is  contained  in 
Appendix  B. 

2.  Primary  Functions  and  Associated  Secondary  Functions 

The  upper  levels  of  the  IDEF^  diagrams  provide  a  method  to  display  the  importance 
of  certain  key  functions  which  the  authors  have  identified  as  primary  functions  required 
to  conduct  TT&C.  Corresponding  secondary  functions  will  be  identified  but  later 
discussed  in  the  following  section. 
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Figure  1,  The  TT&C  Process,  illustrates  the  Top  level  of  the  TT&C  process.  This 
diagram  shows  all  the  inputs,  outputs,  controls,  and  mechanisms  associated  with  the  top 
level.  The  essential  components,  both  required  for  and  result  of  the  process,  were 
identified  and  placed  on  the  top  level  diagram  indicating  their  contribution. 

At  the  top  of  the  figure,  the  four  major  controlling  factors  are  listed:  Space  Vehicle 
Requirements,  Mission  Need  Statement,  Space  Policy,  and  Support  Requirements.  These 
controls  tend  to  highlight  the  long  term  requirements  pertaining  to  the  overall  role  or 
mission  of  a  space  vehicle  and  ensuring  its  health  over  time.  They  are  used  to  establish 
doctrine,  policies,  and  standard  operating  procedures  (SOP)  necessary  for  the  proper 
utilization  of  any  space  asset. 

Located  on  the  left  are  the  inputs  to  the  TT&C  process:  User  Tasking,  User 
Feedback,  and  Space  Vehicle  (SV)  Requirements.  Basically,  inputs  act  as  the  initial 
starting  mechanism  to  the  process.  They  are  a  response  to  a  need  that  must  be  fulfilled  in 
the  short  term  unlike  controls  which  involve  long  term  concerns.  The  user  places  the 
process  into  motion  by  providing  a  task  to  a  controlling  authority  of  a  military  space  asset 
or  in  stating  recommendations  concerning  outcomes  of  previous  tasking.  These  methods 
are  known  as  User  Tasking  and  User  Feedback,  respectfully.  It  is  important  to  note  that 
Space  Vehicle  Requirements  acts  as  both  a  control  and  an  input.  During  the  design  of  a 
space  vehicle,  specific  handling  methods  and  limitations  are  incorporated  to  provide  as 
long  a  life  as  possible.  However,  as  a  system  reacts  to  its  environment,  unforeseen 
abnormalities  tend  to  occur  and  must  be  corrected  or  compensated  for  in  the  short  term  to 
avoid  damage  or  loss  of  the  space  vehicle. 

Listed  at  the  bottom  of  the  diagram  are  the  three  primary  resources  which  aid  in 
supporting  the  process  of  conducting  TT&C.  Facilities  provide  the  structures  which 
house  the  Computer  Hardware  &  Software  elements  and  their  operators  and  maintainers 
known  as  Personnel. 
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The  desired  results  of  this  process  are  Evaluation  /  Status  reports  concerning  the 
system  and  mission  data  requested  by  the  user  which  initiates  User  Feedback.  This  is 
simply  a  broad  look  at  the  TT&C  process.  Further  understanding  of  the  process  is 
provided  within  the  next  level  diagrams. 

Figure  2,  Conduct  TT&C  Primary  Functions,  illustrates  the  four  primary  functions 
required  to  conducting  TT&C.  They  are  characterized  as  the  following:  Perform 
Planning,  Perform  Support  &  Networking,  Conduct  Operations,  and  Conduct  System 
Analysis.  The  IDEF^,  diagram  illustrates  the  interrelationship  of  those  four  key  functions. 
It  is  able  to  accomplish  this  by  highlighting  the  dominating  outputs  of  each  function  and 
mapping  them  as  inputs  to  the  others. 

An  overview  of  the  process  shows  initially  that  it  begins  with  a  planning  stage. 
User  tasking,  in  conjunction  with  available  assets,  SV  requirements,  governing  policies, 
and  other  initial  requests,  allows  the  creation  of  an  operational  plan.  This  plan  becomes 
essential  in  identifying  and  ensuring  the  proper  configuration  of  resources  and  prioritizing 
of  assigned  missions.  Throughout  the  process  a  continuous  planning  cycle  is  achieved  by 
maintaining  feedback  loops  between  the  functions  which  allows  for  modification  and 
improvement  to  the  original  operations  plan. 

The  next  stage.  Perform  Support  and  Networking,  involves  coordination  of  all 
required  assets,  which  includes  items  such  as  remote  antenna  sites,  computer 
workstations  and  their  operators.  The  proper  execution  of  the  plan  is  assured  by 
developing  a  specific  resource  configuration  which  will  be  utilized  by  the  personnel 
involved  in  the  conducting  of  actual  operations.  Feedback  to  the  planning  stage  is  in  the 
form  of  listing  available  assets  and  stating  needs  for  continued  support  capability  such  as 
personnel  training  and  scheduling  down  time  for  required  maintenance. 

The  main  purpose  outlined  in  this  process  is  to  produce  results  for  the  user.  These 
results  are  derived  from  the  third  stage,  Conduct  Operations,  in  the  forms  of  user 
requested  mission  data  to  support  military  operations  or  reports  to  superiors  which  detail 
current  status  and  efficiency  of  the  TT&C  facility. 
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Outputs,  that  remain  internal  to  the  process  at  this  level,  were  non-immediate 
recommended  actions  which  would  be  placed  in  the  operations  plan  to  ensure  the 
continued  health  of  the  space  vehicle  and  status  of  both  the  SV  and  ground  facility 
required  for  system  evaluation. 

It  is  important  to  note  that  the  final  stage  is  not  simply  delivery  of  mission  data  to 
the  user.  There  exists  an  internal  method  of  analyzing  the  complete  process  through  the 
use  of  reports,  evaluations,  and  recommendations  which  allows  for  system  improvements. 
Conduct  System  Analysis  is  the  last  of  the  primary  functions  detailed  in  the  IDEFo 
diagram.  It  includes  internal  feedback  to  the  other  functions  in  an  effort  to  achieve  the 
most  efficient  mode  of  operation.  Recommended  Actions  are  outputs  of  this  stage  which 
attempt  to  rectify  abnormalities  identified  in  the  system. 

In  the  concluding  part  of  this  section,  the  next  level  of  each  primary  function  is 
diagrammed  and  discussed.  The  functions  which  support  any  given  primary  function  are 
known  as  secondary  functions.  These  functions  are  listed  in  the  following  sub-sections 
with  their  associated  primary  function;  however,  the  secondary  function  definitions  are  all 
located  in  Section  C.3  of  this  chapter. 

a.  Perform  Planning 

This  primary  function  involves  the  correlation  of  multiple  inputs,  identifies 
potential  options  and  presents  a  final  strategy  which  is  then  reintroduced  into  the  system 
and  accomplished  over  a  period  of  time.  The  IDEFq  diagram  for  this  function  appears  in 
Figure  3,  Perform  Planning. 

ASSOCIATED  SECONDARY  FUNCTIONS 

•  Provide  Space  Force  Deployment 

•  Perform  Payload  Reconfiguration 

•  Provide  Schedule  Addition 

•  Perform  Operations  Planning 
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These  next  level  functions  were  determined  to  be  the  major  parts  of  the  TT&C 
Planning  process.  As  stated  earlier,  the  goal  of  this  primary  function  was  the  creation  of 
the  Operations  Plan.  This  plan  is  identified  as  a  master  schedule  which  outlines  what 
needs  to  be  done  to  a  SV,  how  it  will  be  done,  and  who,  with  what  resources,  will  do  it. 
To  develop  this  plan,  a  series  of  minor  plans  are  formulated  and  merged  along  with 
inputed  recommended  actions.  The  driving  force  behind  prioritizing  mission  related 
actions  is  user  tasking  and  SV  requirements.  Perform  Operations  Planning  accomplishes 
this  task  by  acting  as  the  main  merging  function.  It  is  here  that  the  routine  schedule  for 
SV  monitoring  and  mission  tasking  occurs  based  on  support  needs,  available  assets  and 
standard  operating  procedures.  A  continual  loop  for  changes  to  the  plan  are  provided  for 
with  the  input.  Schedule  Modification.  Based  on  needs  which  must  be  acted  upon  in  the 
short  term.  Provide  Schedule  Additions  becomes  the  avenue  for  the  user  and  others 
within  the  system  to  work  into  the  schedule  critical  modifications.  Finally,  it  was 
determined  that  the  functions  Provide  Space  Force  Deployment  and  Perform  Payload 
Reconfiguration  were  aspects  of  the  TT&C  process  that  required  special  handling  above 
what  would  normally  be  known  as  routine  activities.  Their  output  would  be  the  drafting 
of  a  deployment  plan  and  reconfiguration  plan,  respectfully,  which  would  be  merged  with 
the  routine  plan.  Once  again,  this  allows  for  the  creation  of  a  prioritized  schedule  known 
as  the  Operations  Plan  which  directly  impacts  both  conducting  operations,  and  support 
and  networking  arrangements. 

b.  Perform  Support  and  Networking  Functions 

Once  the  Operations  Plan  has  been  formulated,  it  is  the  primary  task  of  the 
Perform  Support  and  Networking  function  to  ensure  availability  of  required  assets  and 
resources.  The  primary  output  is  the  establishment  of  a  Resource  Configuration.  The 
ability  to  assign  control  and  authority  of  individual  assets  provides  the  foundation 
necessary  to  link  all  other  functions  to  their  required  resources  in  an  effort  to  support  all 
aspects  of  a  TT&C  system.  The  supporting  secondary  functions  are  listed  below  and  their 
interrelationship  is  displayed  in  Figure  4,  Perform  Support  and  Networking. 
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ASSOCIATED  SECONDARY  FUNCTIONS 


•  Conduct  Training 

•  Conduct  Logistics 

•  Conduct  Maintenance 

•  Allocate  Resources 

The  operations  plan  is  seen  as  the  input  which  schedules  certain  non-operational 
activities  to  conunence.  This  plan  is  further  supported  by  internal  reports  which  outline 
additional  concerns  surrounding  those  activities.  These  activities  include  scheduling 
simulator  time  for  operators  or  allowing  them  time  to  attend  training  courses  to  provide 
improved  performance.  This  involves  the  function  known  as  Conduct  Training.  As  these 
training  opportunities  are  conducted,  feedback  concerning  the  outcome  of  these  activities 
begins  with  the  delivery  of  personnel  qualification  status  updates.  Qualified  personnel 
are  counted  on  the  available  assets  report  while  deficiencies  are  highlighted  in  the  support 
needs  report.  Both  of  these  reports  eventually  arrive  back  at  the  planning  stage  to  start 
the  process  all  over  again. 

Conduct  Maintenance  works  along  the  same  lines  as  that  of  the  function. 
Conduct  Training.  The  main  difference  is  the  scheduling  of  hardware  and  software 
components  vice  personnel  activities.  It  is  important  to  provide  down  time  for 
maintenance  work,  but  doing  so  removes  an  asset  from  use  for  a  period  of  time. 

Maintenance  work  ensures  the  continued  health  of  a  given  TT«&C  resource  and 
as  such  must  be  scheduled  for  by  the  planners.  The  feedback  to  the  planners  begins  with 
the  maintenance  status  report  which  is  sent  to  be  added  to  both  the  support  needs  and 
available  assets  reports. 

The  logistic  schedule  is  the  result  of  the  function.  Conduct  Logistics.  After 
reviewing  inputs  to  the  function,  non-flight  essential  support  needs  are  identified  and  a 
plan  of  action  is  drafted.  This  logistic  schedule  states  activities  that  are  occurring  to 
assure  delivery  of  determined  support  needs. 
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The  final  stage  for  merging  all  the  above  information  is  called  Allocate 
Resources.  Controlled  by  standardized  support  requirements,  this  function  takes  all 
inputs  and  interprets  resource  needs.  Conflicts  in  resource  assignment  are  handled 
through  the  prioritization  of  missions  established  in  the  operations  plan.  As  previously 
stated,  the  configuration  of  resources  is  the  focus  of  this  primary  function.  This  output 
greatly  affects  how  smoothly  operations  will  be  conducted. 

Although  not  shown  in  the  diagram,  the  primary  function.  Perform  Support  and 
Networking,  provides  the  additional  foundation  for  Communication  Connectivity  and 
Security.  Conununication  Connectivity  is  the  ability  to  provide  secure  primary  and 
alternative  communication  links  that  would  connect  control  centers,  remote  ground 
facilities,  and  external  users  /  facilities.  Connectivity  would  be  comprised  of  the 
following:  LAN  /  WANs,  data  link  terminals,  conunercial  services,  military 

communication  satellite,  and  domestic  commercial  communication  satellites.  Security  is 
the  ability  to  protect  against  those  threats  identified  in  DOD  Command  &  Control 
Warfare  (C2W)  /  Information  Warfare  (IW)  assessment  documents.  Security  capabilities 
shall  encompass  the  following:  system,  personnel,  information,  physical, 

communications,  emanations,  and  computer  systems. 

c.  Conduct  Operations 

The  Conduct  Operations  function  is  responsible  for  the  execution  of  the 
operations  plan.  The  associated  secondary  functions  are  listed  below  and  a  graphical 
representation  is  given  in  Figure  5,  Conduct  Operations. 

ASSOCIATED  SECONDARY  FUNCTIONS 

•  Provide  Space  Vehicle  Position  and  Orientation  Management 

•  Perform  Constellation  Management 

•  Execute  TTifeC 

•  Disseminate  Mission  Data 
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Figure  5,  Conduct  Operations 
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If  the  planning  stage  were  known  as  the  brains  of  the  TT&C  process,  then  the 
operations  stage  is  its  heart.  It  is  here  that  the  system  answers  the  user's  tasking  and 
provides  the  desired  results.  It  begins  with  the  function.  Execute  TT&C,  where  signals 
sent  from  participating  space  vehicles  are  received.  These  signals  are  processed  to  reveal 
the  information  that  they  are  carrying.  The  diagram  labels  the  signals  as  either  a  contact 
track  or  telemetry  data.  Contact  tracks  provide  information  on  tracking  data  which  is 
utilized  in  determining  a  SV  position  and  orientation.  Whereas,  telemetry  data  delivers 
information  pertaining  to  the  SV's  health  status  and  associated  mission  related  data.  At  a 
later  point,  the  health  status,  known  as  SV  System  Status,  along  with  Ground  System 
Status  gathered  from  within  the  process  of  executing  TT&C,  becomes  an  input  for 
analysis  of  the  system's  performance.  Mission  data  is  sent  to  the  resources  capable  of 
disseminating  it  to  the  user  in  a  form  usable  by  that  user. 

Commanding  a  space  vehicle  is  an  ability  critical  to  executing  TT&C.  A 
command  to  reorient  a  SV  begins  with  a  requirement  for  increased  accuracy  in 
determining  the  position  of  the  SV.  Position  and  orientation  management  allows  for 
further  precision  of  the  tracking  data.  If  the  SV  is  associated  with  additional  SV's, 
constellation  management  will  provide  any  adjustment  recommendations  to  ensure  the 
integrity  of  that  constellation.  Time  sensitive  actions  are  sent  directly  to  the  function. 
Execute  TT&C,  to  be  processed  into  commands.  These  actions  normally  involve 
preventing  or  correcting  an  abnormality  which  could  damage  the  SV.  Non-immediate 
recommended  actions  are  held  until  they  can  be  incorporated  into  the  operations  plan. 
The  plan  contains  a  list  of  commands  that  will  be  transmitted  to  the  SV  at  a  specified 
time.  This  list  and  any  inmiediate  recommended  actions  are  converted  into  appropriate 
command  language  and  transmitted  to  the  SV  as  scheduled. 

Finally,  the  figure  shows  that  internal  reports  are  merged  and  prepared  in  the 
function.  Disseminate  Mission  Data.  It  is  through  this  route  that  users  and  other 
governing  authorities  receive  requested  reports  on  the  status  of  the  TT&C  process  and 
results  of  evaluation  analysis. 
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d.  Conduct  System  Analysis 

Conduct  System  Analysis  is  the  last  of  the  four  primary  functions,  and  through 
its  output,  a  continual  feedback  loop  within  the  TT&C  process  is  established.  This 
feedback,  in  the  form  of  internal  reports  and  recommended  actions  to  correct  for 
abnormalities,  allows  the  controlling  agency  to  observe  its  performance,  identify 
deficiencies  and  provide  an  avenue  for  improvement  and  growth.  This  function  will 
present  current  as  well  as  time  trended  system  performance  for  evaluation  by  outside 
sources.  Figure  6,  Conduct  System  Analysis,  illustrates  how  the  five  secondary  functions, 
listed  below,  enable  the  process  to  acquire  this  detailed  look  at  itself. 

ASSOCIATED  SECONDARY  FUNCTIONS 

•  Determine  Ground  System  Status 

•  Provide  Ground  Evaluation 

•  Determine  SV  System  Status 

•  Provide  Payload  /  Platform  Evaluation 

•  Perform  System  Analysis 

The  analysis  is  conducted  in  three  stages:  a  look  at  the  ground  segment,  a 
separate  look  at  the  SV  segment,  and  combined  look  to  provide  an  overall  evaluatiori  of 
system  performance.  Analysis  begins  with  current  status  reports  being  delivered  by 
operations  concerning  both  the  ground  and  SV  segments.  Additional  feedback  from  the 
user  is  utilized  to  evaluate  the  quality  of  the  product  produced  by  the  space  vehicle.  The 
secondary  functions  dealing  with  determining  ground  and  SV  systems  status  receives 
their  respected  inputs  and  derives  a  health  and  status  condition  on  each  segment.  Any 
abnormalities  requiring  immediate  corrective  response  is  accompanied  with  the  activation 
of  an  alarm  along  with  being  highlighted  on  the  health  and  status  report. 
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It  is  the  functions  which  provide  evaluations  of  the  segments  that  actively  seek 
out  the  cause  of  a  problem  and  determine  the  degradation  of  a  system.  The  findings  are 
included  in  the  performance  reports  and  sent  for  final  analysis. 

Perform  System  Analysis  is  the  final  function  which  merges  all  the  information 
inputed  and  formulates  the  recommended  actions  necessary  to  rectify  any  abnormality.  It 
takes  a  complete  look  at  the  total  process  to  ensure  that  actions  taken  on  one  particular 
system  does  not  adversely  affect  other  systems.  The  implementation  of  internal  reports 
grants  the  other  primary  functions  an  opportunity  to  monitor  their  overall  effectiveness 
based  on  time  trended  performance  evaluations.  It  is  these  evaluations  that  create  a  loop 
within  the  TT&C  process  allowing  feedback  between  all  activities. 

3.  Secondary  Functions  and  Associated  Sub-Functions 

The  following  section,  along  with  the  data  dictionary  found  in  Appendix  B, 
provides  further  insight  into  the  process  of  TT&C.  The  secondary  functions,  the 
immediate  level  which  supports  the  primary  functions,  are  listed  in  alphabetical  order. 
Their  definitions  will  include  redefining  essential  inputs,  outputs,  controls  and  resources. 
Sub-functions  are  simply  the  next  level  in  the  process  chain.  They  directly  support  a 
specific  secondary  function  and  will  be  listed  immediately  following  the  definition  of  that 
function.  It  is  important  to  note  that  some  secondary  functions  listed  in  this  text  are  not 
associated  with  any  sub-functions.  The  authors  determined  that  certain  functions  required 
further  break  down  in  order  to  better  aid  the  decision  maker's  understanding  of  the  TT&C 
process.  The  remaining  functions,  as  well  as  the  sub-functions,  were  basically  self 
evident  and  no  further  insight  was  required. 

a.  Allocate  Resources 

This  is  the  ability  to  interpret  SV  support  requirements  into  near  term 
equipment  utilization  schedules  for  all  elements  of  satellite  control.  The  key  inputs  being 
an  operations  plan,  internal  reports,  a  logistic  schedule,  maintenance  asset  status,  and 
personnel  qualification  status.  Key  outputs  are  resource  configuration,  support  needs,  and 
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available  assets.  A  single  controlling  factor  is  identified  as  support  requirements.  Key 
resources  are  personnel  and  computer  hardware  &  software. 

ASSOCIATED  SUB-FUNCTIONS 

•  Perform  Scheduling  of  Operations  per  Operator 

•  Perform  Network  Scheduling 

•  Establish  Pre-Designated  Network  Configurations 

b.  Conduct  Logistics 

This  provides  the  capability  of  integrating  non-flight  essential  supporting 
elements  into  an  efficient  logistic  plan.  Key  inputs  are  the  operations  plan  and  internal 
reports  such  as  a  logistic  request.  The  output  being  the  logistic  schedule.  As  always  with 
logistics,  the  key  resource  is  personnel  required  to  take  action. 

c.  Conduct  Maintenance 

This  is  the  ability  to  perform  routine,  periodic,  and  unscheduled  /  time  critical 
maintenance  support  on  ground  segment  and  related  facilities.  Associated  inputs  to  this 
function  are  the  operations  plan  and  internal  reports.  The  key  output  is  the  maintenance 
asset  status  report.  The  key  resource  to  this  secondary  function  is  the  personnel  required 
to  perform  maintenance  tasking. 

ASSOCIATED  SUB-FUNCTIONS 

•  Provide  Maintenance  Personnel 

•  Perform  Routine  /  Periodic  Maintenance 

•  Perform  Logistic  Support 
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d.  Conduct  Training 

This  is  the  ability  to  provide  realistic  training  by  utilizing  classroom,  on-the-job, 
and  simulator  environments.  The  key  inputs  associated  with  this  function  are  the 
operations  plan  and  internal  reports.  The  output  from  this  function  will  be  a  personnel 
qualification  status  report.  The  key  resource  is  personnel,  specifically  instructors  when 
dealing  with  training  evolutions. 

ASSOCIATED  SIJB-FUNCTIONS 

•  Provide  Maintenance  Personnel 

•  Perform  Routine  /  Periodic  Maintenance 

•  Perform  Logistic  Support 

e.  Determine  Ground  System  Status 

This  is  the  method  to  detect  and  isolate  problems  in  order  to  determine  ground 
segment  current  status.  The  key  input  to  this  function  is  the  Ground  Segment  Status. 
Outputs  to  this  function  are  Alarms  and  Ground  Segment  Health  and  Status.  Resources 
affecting  this  function  are  the  Computer  Hardware  and  Software. 

/.  Determine  SV  System  Status 

This  is  an  ability  to  provide  a  method  to  detect  and  isolate  problems  in  order  to 
determine  the  space  vehicle  system's  current  status.  The  key  inputs  to  this  function  are 
SV  System  Status  and  User  Feedback.  Outputs  include  Alarms  and  SV  Health  &  Status. 
The  single  control  affecting  this  function  is  SV  Requirements.  The  two  resources 
involved  are  Personnel  and  Computer  Hardware  &  Software. 
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g.  Disseminate  Mission  Data  and  Other  Information 

This  allows  for  the  capability  of  distributing  processed  and  unprocessed  data 
from  the  satellite  control  node  to  the  C2  node  (user).  Additional  information  required  by 
the  user  outside  of  mission  related  data  would  also  be  disseminated.  Key  inputs  to  this 
function  are  Mission  Data  (Processed  and  Unprocessed)  and  Internal  Reports.  The 
associated  outputs  are  Distributed  Mission  Data  (Processed  and  Unprocessed)  and 
Evaluation  /  Status  Reports. 

ASSOCIATED  SUB-FUNCTIONS 

•  Disseminate  Processed  Data 

•  Ability  to  Disseminate  Unprocessed  Mission  Data 

•  Disseminate  Evaluation  /  Status  Reports 

h.  Execute  TT&C 

This  function  maintains  the  systems  ability  to  receive  telemetry  data,  gather  and 
process  azimuth  and  elevation  data,  as  well  as  other  pertinent  navigation  information. 
Also  included  in  the  function  is  the  transmitting  of  commands  necessary  to  control  both 
payload  and  maintain  health  and  status  of  the  platform.  Supporting  functions  include; 
receive  data,  collect  and  process  pointing  data,  determine  range  and  range  rate,  transmit 
payload  commands,  maintain  health  and  status,  provide  antenna  connectivity,  concurrent 
events,  and  establish  timing  accuracy.  Key  inputs  to  this  function  are  the  Operation  Plan, 
Immediate  Recommended  Actions,  Recommended  Action,  Telemetry  Data,  Contact  Data, 
and  Resource  Configuration.  Outputs  associated  with  this  function  are  Commands,  SV 
System  Status,  and  Ground  System  Status.  Resources  belonging  with  this  function  are 
Computer  Hardware  &  Software,  Facilities,  and  Personnel. 


35 


ASSOCTATED  STTB-FUNCTIONS 


•  Determine  Range 

•  Collect  and  Process  Pointing  Data 

•  Calculate  Azimuth  and  Elevation 

•  Establish  Timing 

•  Receive  Data  &,  Command  Verification 

•  Data  and  Control  Commands 

L  Perform  Constellation  Management 

This  is  the  ability  to  determine,  predict,  and  adjust  as  necessary  the  SV  orbital 
parameters  in  order  to  maintain  constellation  integrity.  The  key  input  associated  with  this 
function  is  Positioning  Data.  The  resultant  output  being  Constellation  Adjustment.  The 
associated  control  with  this  function  is  Space  Vehicle  Requirements. 

j.  Perform  Operations  Planning 

This  is  the  ability  to  perform  all  planning  functions  to  include;  mission  planning, 
contact  objectives,  command  generating,  contingency,  and  time  sensitive  planning. 
Inputs  involved  are  Deployment  Plan,  User  Tasking,  SV  Requirements,  Schedule 
Modification,  Support  Needs,  Reconfiguration  Plan,  Recommended  Actions,  Internal 
Reports,  and  Available  Assets.  The  key  output  to  this  function  is  the  Operations  Plan. 
Controls  affecting  this  function  are  Space  Policy,  and  the  Mission  Need  Statements.  A 
common  resource  associated  with  this  function  is  Personnel. 
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ASSOCIATED  SUB-FUNCTIONS 


•  Define  Contact  Objectives 

•  Perform  Command  Generation 

•  Perform  mission  Planning 

k.  Perform  Payload  Reconfiguration 

This  is  the  ability  to  provide  a  planning  responsiveness  to  users  that  involves 
possible  changes  to  the  control  of  the  platform  or  payload  systems.  The  key  inputs 
associated  with  this  function  are  the  User  Tasking  and  SV  Requirements.  The  associated 
output  being  the  Reconfiguration  Plan.  Controls  related  to  this  function  are  SV 
Requirements  and  Mission  Need  Statements. 

/.  Petform  System  Analysis 

This  is  the  ability  to  evaluate  overall  system  performance.  It  would  include 
conducting  long  term  trend  analysis  and  capacity  management  evaluation.  Key  input 
parameters  associated  with  this  function  are  the  SV  Performance  Report  and  the  Ground 
Performance  Report.  Outputs  from  this  function  are  Internal  Reports  and  Recommended 
Actions.  Controls  affecting  this  function  are  the  Antenna  Network,  Communication 
Capacity,  Satellite  Operations  Center  Requirements,  and  System  Requirements. 
Resources  belonging  to  this  function  are  the  Processor,  Software,  Capacity  Models,  and 
Trending. 

ASSOCIATED  SUB-FUNCTIONS 

•  Evaluation  of  Overall  System  Performance 

•  Conduct  Long  Term  Tend  Analysis 
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•  Evaluate  System  Capacity 


m.  Provide  Ground  Evaluation 

This  provides  for  the  ability  to  quickly  assess,  isolate,  and  correct  ground  system 
failures.  Inputs  belonging  to  this  function  are  Alarms  and  Ground  Segment  Health  and 
Status.  Outputs  associated  are  the  Ground  Performance  Report.  Resources  falling  under 
this  function  are  Personnel  and  Computer  Hardware  &  Software. 

ASSOCIATED  SUB-FUNCTIONS 

•  Conduct  Isolation  of  Ground  System  Problem 

•  Notify  Operator 

•  Recoimnend  Corrective  Action 

n.  Provide  Payload  /  Platform  Evaluation 

The  function  maintains  the  ability  to  assess,  verify,  and  conduct  detailed 
performance  analysis  either  during  or  after  a  SV  contact.  Key  inputs  to  this  function  are 
the  SV  Health  &  Status  and  the  Alarms.  The  output  is  the  SV  Performance  Report.  The 
key  governing  control  to  this  function  is  SV  Requirements.  Resources  affecting  this 
function  are  the  Personnel  and  Computer  &  Hardware  &  Software. 

ASSOCIATED  SUB-FUNCTIONS 

•  Conduct  Isolation  of  System  Problem 

•  Notify  Operator 

•  Recommend  Corrective  or  Safmg  Action 
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•  Verify  Mission  Events 


0.  Provide  Space  Force  Deployment 

This  function  provides  the  planning  for  all  aspects  of  Space  Force  Deployment. 
Activities  involved  include  pre-launch  preparations,  launch  support,  early  orbit  checkout, 
and  positioning  of  the  SV. 

p.  Provide  Space  Vehicle  Position  and  Orientation  Management 

This  function  provides  the  ability  to  determine,  predict,  and  adjust  orbital 
parameters  of  the  SV  within  specified  limits.  The  input  is  the  Tracking  Data.  The 
outputs  includes  Position  Data,  Immediate  Recommended  Action,  and 
Non-Recommended  Action.  The  control  on  this  function  is  SV  Requirements. 

ASSOCIATED  SUB-FUNCTIONS 

•  Determine  Space  Vehicle  Position  and  Orientation 

•  Predict  Position  and  Orientation 

•  Adjust  Orbital  Parameters 

q.  Provide  Schedule  Additions 

This  function  provides  a  responsive  capability  to  the  SV  system  user  (either 
external  or  internal  )  to  accomplish  non  -  nominal  or  emergency  support  requirements 
(mission  tasking).  This  entails  formulating  schedule  options  and  resolving  possible 
schedule  conflicts.  Key  inputs  to  this  function  are  User  Tasking,  Non-Immediate 
Recommended  Action,  and  the  Operations  Plan.  The  output  to  this  function  is  the 
Schedule  Modification.  Controls  acting  on  this  function  are  the  Mission  Need  Statements 
and  Space  Policy.  Personnel  is  the  essential  resource  involved  with  this  function. 
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ASSOCIATED  SUB-FUNCTIONS 


•  Determine  Schedule  Options 

•  Resolve  Schedule  Conflictions 

•  Execution  of  Schedule  Addition 

D.  SUMMARY 

This  chapter  presented  a  generic  look  at  the  TT&C  process  by  identifying  essential 
functions  and  their  interrelationship  amongst  each  other.  This  was  achieved  by 
graphically  presenting  the  four  primary  functions,  associated  secondary  and  sub-functions 
in  a  DOD  accepted  activity  modeling  technique.  By  understanding  the  process,  the  first 
step  toward  providing  a  comprehensive  guideline  to  aid  the  decision  maker  is  established. 
This  guidance  would  focus  the  decision  maker's  areas  of  concern  surrounding  future 
proposed  TT&C  candidate  architectures. 

However,  to  ensure  a  completely  informed  decision,  it  will  be  necessary  to  examine 
present  architectures  and  develop  a  method  to  objectively  rank  them.  This  will  be  the 
intentions  of  the  following  two  chapters. 
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III.  CURRENT  TT&C  METHODS  AND  TRENDS 


A.  INTRODUCTION 

To  properly  make  good  judgmental  choices  for  development  of  future  TT&C 
architectures,  it  is  essential  that  the  decision  maker  have  a  well  defined  description  of  the 
current  TT&C  architectures.  Currently,  there  exist  a  multitude  of  TT&C  architectures 
that  could  be  used  to  formulate  this  baseline.  The  options  for  discussion  range  from  both 
national  and  international  military  and/or  commercial  oriented  systems.  This  chapter  will 
limit  itself  in  an  attempt  to  provide  an  in-depth  descriptive  look  at  three  well  known 
domestic  options. 

•  Air  Force  Satellite  Control  Network  (AFSCN) 

•  Mission  Control  Center  (MCC),  Johnson  Space  Center 

•  Naval  Satellite  Operations  Center  (NAVSOC) 

These  options  were  chosen  on  the  basis  of  available  material  /  resources  and  their 
non  -proprietary  nature.  The  options  represent  varying  and  distinct  aspects  to  TT&C 
development.  Their  approaches  to  TT&C  range  from  utilizing  historically  proven 
processes  to  the  development  and  integration  of  advanced  control  /  conmiunication 
techniques. 

B.  AIR  FORCE  SATELLITE  CONTROL  NETWORK  (AFSCN) 

1.  History 

The  AFSCN  capability  was  established  in  1959  in  response  to  worldwide  classified 
programs.  Growing  to  match  expanding  user  requirements,  the  AFSCN  went  from 
controlling  just  three  satellites  to  presently  90  plus  satellites  projected  for  the  end  of 
1997.  As  a  result  of  its  ability  to  validate  technology,  the  Space  Ground  Link  System 
(SGLS)  established  by  the  AFSCN  has  become  the  accepted  DOD  standard. 
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2.  Command  Structure 

The  AFSCN  is  under  operational  eontrol  of  the  Air  Force  Space  Command 
(AFSPACECOM),  headquartered  at  Peterson  Air  Force  Base  (AFB).  The  50th  Space 
Wing,  headquartered  at  Falcon  AFB,  is  responsible  for  the  operation  and  management  of 
the  AFSCN.  The  50th  Space  Wing  Organizational  Structure  is  shown  in  Figure  7. 

3.  Baseline  Resources 

a.  Remote  Sites  and  Antenna  Capability 

There  are  sixteen  common-user  TT&C  remote  tracking  stations  spread  out  over 
nine  geographical  locations  shown  in  Table  1.  Three  Remote  Tracking  Stations,  Mahe 
Indian  Ocean  (lOS),  Falcon  Air  Force  Base  (FAFB)  Colorado  Springs  (CTS),  and  Diego 
Garcia  (DGS)  are  single  sided,  that  is  to  say,  they  have  only  one  TT&C  antenna.  Five  of 
the  remaining  six  sites,  Manchester  New  Hampshire  (NHS),  Kaena  Point,  Oahu  Hawaii 
(HTS),  Vandenberg  AFB  (VTS),  Oakhanger  England  (TCS),  and  Guam  (GTS)  are  dual 
sided.  Lastly,  Thule  Greenland  (TTS)  is  triple-sided.  Knowing  that  one  side  can  provide 
services  to  one  Space  Vehicle  (SV)  at  a  time  results  in  the  previously  stated  sixteen 
common-user  TT&C  stations.  An  "S"  band  space-ground  interface  is  utilized  while 
primary  and  alternate  AFSCN  communications  are  maintained  to  the  control  centers. 
[Ref.  7] 

The  AFSCN  Common-User  Non  TT&C  facilities  are  Camp  Parks 
Communication  Annex  (CPC A),  located  at  Pleasanton  CA;  the  Eastern  Vehicle  Checkout 
Facility  (EVCF),  at  Cape  Canaveral  FL;  and  multiple  mobile  systems  can  perform  TT&C 
functions  with  one  SV  at  a  time. 

The  dedicated  eontrol  centers  coordinate  with  the  Operational  Control  Nodes 
(OCNs),  Falcon  Air  Force  Base  and  Onizuka  AFB,  for  the  scheduling  and  allocation  of 
resources.  An  example  would  be  Milstar  Operations  Center  (MOC)  at  Falcon  Air  Force 
Base,  Global  Positioning  System  (GPS)  Master  Control  Station  (MCS)  at  Falcon  Air 
Force  Base,  and  Naval  Space  Operations  Center  dedicated  to  the  FLTSATCOM  program. 
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There  are  five  non  TT&C  Monitor  Stations  (MS)  all  of  which  are  dedicated  to 
GPS.  Of  note,  all  five  MSs  have  "L"  band  omni  antennas  used  for  tracking  and 
monitoring  the  GPS  satellites  (i.e.;  ephemera  data  collection). 


Tracking  Station 

Number  of  Antennas 

New  Hampshire  (NHS) 

2  Space-Ground  Link 
System  (SGLS) 

Vandenberg  AFB  (VTS) 

2SGLS 

Kaena  Point  Oahu  (HTS) 

2  SGLS 

Guam  (GTS) 

2  SGLS 

Indian  Ocean  (lOS) 

1  SGLS 

Thule  Greenland 

3  SGLS 

Oakhanger  England  (TCS) 

2  SGLS 

Diego  Garcia  (DGS) 

1  SGLS 

Falcon  AFB  (CTS) 

1  SGLS 

Table  1 .  AFSCN  Common  User  TT&C  Tracking  Stations 


h.  Personnel 

There  are  approximately  1200  personnel  assigned  to  the  AFSPACECOM.  With 
the  responsibility  of  over  90  plus  satellites  to  control,  this  manpower  level  allows  for  a 
personnel  to  satellite  payload  ratio  of  8:1. 

c.  Supporting  Facilities 

Supporting  facilities  for  the  AFSCN  is  provided  within  the  command  structure 
itself.  These  supporting  facilities  include  some  of  the  following: 

•  50th  Logistics  Group  -  manages  logistic  support  activities  for  the  ground 
control  systems. 

•  50th  Support  Group  -  maintains  and  operates  Falcon  Air  Force  Base  which 
would  include  physical  security,  and  utilities  &  environmental  support. 
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•  750th  Space  Group  -  located  at  Onizuka  AFB  CA,  provides  backup  for  TT&C 
support  to  AFSCN  users. 

4.  Operational  Methodology 

The  AFSCN  is  considered  to  be  a  centralized  network  revolving  around  the  primary 
and  secondary  Mission  Control  Complex  (MCC)  located  at  either  Falcon  AFB  or 
Onazuka  AFB  respectively.  The  operating  methodology  for  the  AFSCN  is  known  as  the 
Command  and  Control  System  (CCS).  The  CCS  takes  advantage  of  a  centralized 
command  &  control  structure  which  provides  for  user  dedicated  data  processing. 
Inherent  to  the  CCS  system  the  Remote  Tracking  Stations  (RTS)  utilize  the  Remote 
Control  and  Status  Equipment  (RCSE)  which  allows  the  RTS  to  act  as  a  geographic 
disperse  relay  site.  This  enables  the  RTS  to  directly  relay  the  entire  received  telemetry 
stream  back  to  a  CCS-  compatible  MCC  or  act  as  a  relay  for  SV  commands  from  the  CCS 
MCC  to  the  SV.  Because  of  centralized  location  of  the  main  processors,  all  processing 
and  analysis  is  conducted  at  the  MCC  site.  As  a  result,  real  time  access  to  the  entire 
telemetry  (TLM)  stream  is  possible.  The  CCS  architecture  consists  of  the  following 
major  hardware  items: 

•  Main  Processors  -  Each  MCC  contains  two  main  processors  referred  to  as  the 
Contact  Support  Processor  (CSP)  and  the  Planning  and  Evaluation  Processor 
(PEP).  [Ref.  9] 

•  Processor  Peripherals  -  Storage  peripherals  include  Direct  Access  Storage 
Devices  (DASDs)  and  magnetic  tape  units.  Display  peripherals  include 
interactive  display  terminals  and  hardcopy  printers.  [Ref.  9] 

•  Classified  Interface  Unit  (CIU)  -  This  unit  receives  and  transfers  data  from  the 
Command  Contact  Support  Equipment  Group  (CSEG)  and  Isolation  Review 
Unit  (IRU)  to  the  processor.  Data  includes  pointing  commands,  RTS 
configuration  directives,  and  SV  commands.  [Ref.  9] 
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•  Unclassified  Interface  Unit  (UIU)  -  This  unit  receives  and  transfers  data  to  and 
from  the  CIU  via  the  IRU  and  or  Command  CSEG.  Data  includes  tracking  and 
RTS  status,  RCSE  ground  directives,  and  encrypted  SV  commands.  [Ref.  9] 

•  Isolation  Review  Unit  -  Receives  data  being  transferred  from  the  CIU  to  the 
UIU  and  returns  data  that  does  not  pass  security  reviews  back  to  the  CIU.  [Ref. 
9] 

•  Telemetry  Interface  Unit  (TIU)  -  The  TIU  receives  data  from  the  telemetry 
CSEG  and  transfers  the  data  to  the  CSP.  [Ref.  9] 

•  Telemetry  CSEG  -  The  telemetry  CSEG  preprocesses,  synchronizes,  and 
decrypts  telemetry  data.  [Ref.  9] 

•  Command  CSEG  -  The  CSEG  encrypts  command  data  originating  in  the  CSP 
and  decrypts  command  echo  data.  [Ref.  9] 

A  descriptive  diagram  can  be  found  below  in  Figure  8,  AFSCN  Satellite  Control 


Architecture. 


9  sites  c&c 

-  Partially  automated 

-  Operations: 

-  LEO 

~  Norma)  ops 
~  Anomaly  resolution 


Figure  8,  AFSCN  Satellite  Control  Architecture,  From  Ref.  10 


46 


5.  Strengths  and  Capabilities 

The  AFSCN  architecture  strengths  lie  in  the  following  areas: 

•  Establishment  of  a  worldwide  antenna  network  providing  global  coverage 

•  Support  launch  and  space  force  deployment 

•  Current  infrastructure  allows  for  the  management  of  a  large  volume  of  space 
vehicles 

•  On  -  orbit  commanding  /  support  of  SVs 

C.  NAVAL  SATELLITE  OPERATIONS  CENTER  (NAVSOC) 

1.  History 

With  the  development  of  the  TRANSIT  satellite  system  to  meet  Fleet  Navigation 
Requirements,  the  Naval  Satellite  Control  Network  (NSCN)  became  operational  in 
1962.  The  NSCN  currently  provides  support  for  less  then  thirty  satellites.  With  only  three 
remote  sites  and  one  SGLS  antenna  per  site,  the  NSCN  is  acclaimed  for  its  use  of  open 
and  distributed  architecture  strategies  and  Commercial  Off  the  Shelf  (COTS) 
implementation. 

2.  Command  Structure 

The  Naval  Satellite  Operations  Center  (NAVSOC),  located  at  Point  Mugu  CA, 
provides  the  command  and  control  of  satellite  systems  assigned  by  the  Naval  Space 
Command  (NAVSPACECOM),  headquartered  at  Dahlgren,  VA.  The  NAVSOC  operates 
and  maintains  the  NSCN  which  comprises  all  of  the  satellite  TT&C  ground-based 
hardware  and  software.  A  descriptive  view  of  the  organization  is  provided  in  Figure  9, 
NAVSOC  Organization. 
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Figure  9,  NAVSOC  Organization,  From  Ref.  1 1 


3.  Baseline  Resources 

a.  Remote  Sites  and  Antenna  Capability 

The  NSCN  remote  sites  are  located  in  Table  2,  NSCN  Remote  Sites  and 
Capabilities.  The  basic  configuration  of  each  site  is  similar  except  that  the  Laguna  Peak 
and  Detachment  Alpha  have  the  satellite-ground  link  system  (SGLS)  capability  for 
satellite-to-ground  communications.  Currently  there  are  no  intentions  to  command  from 
the  Guam  site  due  to  the  AFSCN  Automated  Remote  Tracking  Stations  (ARTS) 
integration  plan  which  calls  for  the  sharing  of  AFSCN  antenna  sites  assets  on  an 
as-required  basis.  [Ref.  11] 
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Tracking  Station 

Number  of  Antennas 

Prospect  Harbor,  Maine  (DET  ALPHA) 

2  EHF,  1  SGLS,  1  VHF 

Rosemount,  Minnesota  (DET  BRAVO) 

3  VHF  (Transit  Only) 

FAFB,  Colorado  Springs,  CO  (DET  DELTA) 

1  SGLS  (Shared) 

Laguna  Peak,  CA 

1  SGLS  &  VHF,  1  VHF 

Guam  (DET  C) 

1  SGLS,  1  EHF  (UHF 
Follow-On) 

Table  2.  NSCN  Remote  Sites  and  Capabilities 

The  architecture  at  each  remote  site  comprises  the  following  five  subsystems: 
SGLS  antenna  subsystem,  Doppler  tracking  subsystem,  TT«feC  subsystem.  Integrated 
Satellite  Control  System  (ISCS)  component  subsystem,  and  Communication  subsystem. 
The  Communication  Subsystem  provides  connectivity  to  non-NSCN  systems,  the  other 
remote  sites,  and  NAVSOC  HQ. 

b.  Personnel 

The  NAVSPACECOM  operates  with  a  manpower  level  of  approximately  180 
personnel  and  17  operational  satellites  which  results  in  a  personnel  to  satellite  ratio  of 
approximatley  10:1. 

4.  Operational  Methodology 

The  NAVSOC  uses  a  distributed  architecture  globally  (on  a  WAN  basis)  where  all 
the  components  of  hardware  and  software  are  standardized.  The  basic  configuration  of 
each  site  is  similar,  expect  that  the  Laguna  Peak  and  Detachment  ALPHA  remote  sites 
have  satellite-ground  link  system  (SGLS)  capability  for  satellite-to-ground 
communications.  The  Integrated  Satellite  Control  System  (ISCS)  is  the  methodology  for 
performing  NSCN  satellite  operations.  The  ISCS  takes  advantage  of  VAX  hardware  & 
software  systems  and  uses  the  Naval  Research  Laboratory's  (NRL)  Common 
Environment  for  Testing  (COMET)  /  Command  and  Telemetry  System  (CATS)  software. 
The  NAVSOC  is  currently  progressing  steadily  toward  an  open  architecture  by  utilizing 
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workstations  and  PCs.  Eventually,  the  VAX  systems  will  be  replaced  by  a  combination 
of  PC  type  file  servers  and  workstations. 

Through  the  implementation  of  ISCS  each  RTS  can  perform  the  following 
functions: 

•  Evaluate  telemetry  and  pass  change  only  telemetry  data  to  the  communications 
subsystem  for  transmission  to  NAVSOC  HQ 

•  Evaluate  telemetry  Umits  and  generate  anomaly  alerts. 

•  Store  telemetry  data  in  designated  formats. 

•  Control  antenna  pointing  based  on  satellite  orbital  elements  received  from  the 
external  system 

•  Evaluates  the  ISCS  software  processes  and  generates  anomaly  alerts 

•  Develops  the  schedules  of  all  NSCN  satellite  contacts 

•  Configures  and  controls  ground  station  hardware  components 

•  Construct  and  store  commands  and  command  sequences  and  will  initiate  the 
command  uplink  to  the  satellite 

It  should  be  noted  that  at  the  time  of  this  writing,  NAVSOC  HQ  does  not  have  an 
antenna  on  site  to  provide  SGLS  communications  due  to  the  close  proximity  of  the 
Laguna  Peak  site.  However,  the  distributed  architecture  which  NSCN  employs  allows 
the  NAVSOC  HQ  the  capability  to  control  and  collect  data  from  or  for  any  site  within  the 
NSCN.  A  descriptive  diagram  is  shown  in  Figure  10,  NAVSOC  Satellite  Control 
Architecture.  The  NSCN  is  comprised  of  the  following  major  components: 

•  Remote  Site  ISCS  -  Each  site  contains  a  Micro  VAX  computer  which  is 
connected  to  a  Thinwire  Ethernet  Local  Area  Network  (LAN).  The  LAN 
connects  the  Micro  VAX  to  the  telemetry  and  communications  subsystems  in 
the  normal  operational  mode  by  using  RS-232  interfaces.  [Ref.  11] 
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•  HQ  ISCS  -  This  component  contains  redundant  Micro  VAX  computers  that 
perform  the  previously  mentioned  functions.  [Ref.  11] 

•  ISCS  Software  -  Menu  driven  command  and  control  system  operating  on  a 
Micro  VAX  computer.  Basic  software  consist  of  VMS  operating  system, 
COMET  /  CATS,  NRL  developed  software,  and  NAVSOC  specific  software. 
[Ref.  11] 

•  Communications  -  The  communication  component  links  the  remote  sites  to 
NAVSOC  HQ  and  other  NSCN  sites  through  a  DECrouter.  A  dial  up 
connection  between  remote  sites  and  NAVSOC  HQ  provides  a  backup 
capability  in  degraded  operational  modes.  [Ref.  11] 

•  Intersite  Communications  -  Currently,  all  sites  are  linked  via  multiplexers  on 
56  Kb/sec  leased  lines  and  a  point-to-point  packet  network.  The  point-point 
packet  network  is  implemented  by  the  use  of  a  commercial  network 
architecture  known  as  DECnet.  The  DECnet  uses  one  channel  out  of  8 
possible.  The  remaining  channels  are  used  for  passing  real-time  baseband  data, 
voice  &  fax  communications,  antenna  control,  receiver,  and  bit  synchronizer  if 
the  site  computer  is  not  available.  The  leased  lines  provide  the  data  links 
among  the  three  sites,  allowing  each  site  to  communicate  directly  with 
NAVSOC  HQ.  At  each  site,  the  leased  lines  terminate  in  a  modem,  a  KG-84, 
and  a  DECrouter  hardware  string.  [Ref.  1 1] 
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Figure  10,  NAVSOC  Satellite  Control  Architecture,  From  Ref.  10 


5.  Strengths  and  Capability 

The  NSCN  architecture  exhibits  the  following  strengths  and  capabilities: 

•  COTS  and  International  Standardization  implementation  throughout 
architecture 

•  Distributed  aspect  of  the  system  permits  remote  sites  and  HQ  to  act  as  backup 
allowing  for  multiple  redundant  systems  in  case  of  system  degradation. 

•  High  level  of  automation  allows  for  timely  processing  of  Anomaly  Analysis, 
Alarms,  Corrective  Action  and  Scheduling.  This  also  enables  a  reduction  in 
required  personnel  to  accomplish  these  tasks. 

•  Considerable  potential  for  growth  through  the  implementation  of  the  Plug  -  In- 
Use  concept  allows  access  to  other  non  NSCN  assets.  In  addition,  limited 
commanding  capability  for  UFO  Follow  on  and  FLTSAT  satellites  has  been 
achieved  through  this  method. 


52 


D.  MISSION  CONTROL  CENTER  (MCC),  JOHNSON  SPACE  CENTER 


1.  History 

Since  1964,  the  Mission  Control  Center  (MCC),  located  at  Johnson  Space  Center 
Houston,  has  undergone  a  drastic  metamorphosis  which  enabled  it  to  meet  current  space 
vehicle  mission  requirements  while  meeting  the  present  day  economic  demands.  The 
MCC  takes  advantage  of  both  COTS  and  the  present  day  open  architecture  technology. 
Unlike  the  limited  role  of  the  NSCN,  the  MCC  is  required  to  handle  a  vast  array  of 
mission  tasking;  most  importantly,  that  being  the  manned  space  flights  and  deep  space 
programs. 

2.  Command  Structure 

The  MCC  is  organized  under  the  Director  of  Space  Shuttle  Operations  Office, 
who’s  responsibilities  include  all  aspects  of  NASA's  highly  visible  operation,  the  Shuttle 
Transportation  System  (STS)  Program.  The  Johnson  Space  Center  (JSC),  in  which  the 
MCC  is  an  integrated  part,  and  Kennedy  Space  Center  (KSC)  provide  the  required 
monitoring  capabilities  to  ensure  safe  STS  operations.  The  Director  of  Space  Shuttle 
Operations  delegates  MCC  operations  and  tasking  to  the  manager  of  the  Space  Shuttle 
System  and  Operations  Office.  It  is  this  office  which  is  responsible  for  day  to  day 
manning  of  the  flight  director  position.  These  individual  flight  directors  personally 
oversee  the  operators  of  the  MCC  facility.  Figure  1 1,  MCC  Command  Structure,  depicts 
a  broad  overview  of  the  Space  Shuttle  Program  Office. 
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Figure  11,  MCC  Command  Structure,  From  Ref.  12 
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3.  Baseline  Resources 


a.  Remote  Sites  and  Antennas 

NASA  receives  data  on  S-Band,  C-Band  and  KU-Band  frequencies.  Space 
Shuttle  data  and  voice  is  downlinked  via  TDRSS  Satellites  or  via  ground  stations.  All 
TDRSS  downlink  is  received  at  the  NASA  Johnson  Space  Center  (JSC)  through  the 
White  Sands  Test  Facility  in  New  Mexico.  All  ground  site  downlink  is  received  at 
NASA  Johnson  Space  Center  through  either  Sunnyvale  CA,  Goddard  Space  Flight 
Center  (GSFC)  or  Kennedy  Space  Center  (KSC).  Appendix  C  identifies  all  the  available 
ground  sites  utiUzed  by  NASA  to  receive  Space  Shuttle  downlink. 

b.  Personnel 

By  reducing  maintenance  costs  and  increasing  automation,  the  MCC  has  been 
able  to  reduce  its  staffing  by  180  personnel  while  simultaneously  growing  overall 
operations  capabilities  to  support  Shuttle  and  future  Space  Station  operation 
requirements.  Currently,  the  MCC  conducts  operations  with  approximately  240  flight 
controllers  on  a  three  shift  basis  (80  per  shift)  and  75  ground  controllers  (25  per  shift). 
The  number  of  payload  operators  varies  widely  and  is  payload  specific.  Due  to  the  nature 
and  risk  involved  with  manned  space  flight  the  MCC  operates  with  a  personnel  to  space 
vehicle  ratio  of  approximately  315:1. 

4.  Operational  Methodology  and  Capabilities 

Operational  systems  include  standard  UNK  computer  workstations  using  the  DEC 
Alpha  500  platform  for  console  operations,  the  IBM  RS  6000  for  front  end  processing 
with  the  Loral  LI  550  telemetry  processor  for  data  operations.  All  workstations  are 
interconnected  on  a  Local  Area  Network  (LAN)  utilizing  125,000  ft  of  Fiber  Optic  Cable. 
The  MCC  boast  having  the  worlds  largest  Fiber  Optic  Distributed  Interface  Network 
currently  in  use. 
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MCC  Houston  baselines  the  use  of  Commercial  Off  the  Shelf  (COTS)  software 
and  hardware  where  practical  and  estimates  a  reduction  in  lines  of  code  from  4.6  million 
to  3  million  by  fiscal  year  1999.  Software  standards  for  Terminal  Communications 
Protocol  /  Internet  Protocol  (TCP/IP)  communications  protocol  using  the  Fiber  Data 
Distributed  Interface  (FDDI)  network  standard  form  the  standards  for  the  MCC 
communications  backbone.  Figure  12,  MCC  Satellite  Control  Architecture,  provides  a 
graphical  representation  of  this  architecture. 


-  Highly  automated 

--  Unattended  overnight 
operations 


Figure  12,  MCC  Satellite  Control  Architecture,  From  Ref.  10 


5,  Strengths 

The  strengths  of  the  MCC  methodology  stems  from  its  fundamental  underlying 
principle  which  is  to  build  a  world  class  Mission  Control  Center  able  to  support  multiple 
spaceflight  programs  while  reducing  long  term  operations  and  maintenance  cost.  In 
doing  this  the  MCC  has  been  able  to  construct  a  Mission  Control  Center  that  has  the 
capability  of  providing  rapid  reconfiguration  for  the  support  of  a  variety  of  mission 
objectives  while  maximizing  the  use  of  COTS  hardware  and  software. 
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E.  TRENDS  IN  TT&C 


As  stated  above,  the  strengths  of  the  current  TT&C  systems,  supported  by  the 
documentation  presented  in  Chapter  I,  emphasizes  a  capability  of  doing  business 
differently.  This  necessity  for  change  is  being  driven  by  budgetary  constraints,  reduction 
in  available  resources,  and  the  ever  changing  technological  environment.  This  forces 
organizations  to  incorporate  the  cutting  edge  of  technology  at  the  same  time  ensuring 
lower  life  cycle  cost,  simplified  process,  reduction  in  manpower,  while  maintaining  the 
ability  to  meet  future  program  requirements.  In  the  authors  opinion,  utilizing  this 
approach  would  allow  a  transition  from  the  traditional  60's  mainframe  architecture  to  the 
less  manpower  intensive,  highly  automated,  and  more  standardized  approach  that  is 
becoming  the  signature  of  the  90's. 

The  following  trends  were  identified  as  being  crucial  in  bringing  current  systems 
into  the  90's: 

•  Automation  -  The  ability  to  perform  a  specific  task  without  human  interaction. 
Advantages  of  automation  include  freeing  operator  time  which  may  result  in  a 
reduction  in  manpower  and  act  as  a  safeguard  minimizing  human  error  in  a 
specific  task.  Such  tasks  may  include:  SV  pass  scheduling,  health  monitoring, 
sending  commands,  and  trend  analysis. 

•  Commercial  Off  The  Shelf  (COTS)  -  An  item  of  hardware  or  software  that  has 
been  produced  by  a  contractor  and  is  available  for  general  purchase.  Benefits 
from  COTS  implementation  allows  for  timely  integration  at  a  reduced  cost 
while  using  current  technology.  Examples  would  include  acquiring  the  use  of 
off  the  shelf  operating  environments  such  as  X-Windows  and  commercially 
available  personal  computers  (PC)  /  workstations. 

•  Distributed  System  -  A  decentralized  system  that  is  dispersed  over  an 
interconnected  network.  Benefits  can  include  reduced  cost  as  a  result  of  not 
relying  on  centralized  systems.  This  allows  for  a  system  which  is  multitasked. 


57 


the  capability  to  achieve  a  robustness  and  redundancy  level  which  is  cost 
effective.  An  example  would  be  allowing  a  single  workstation  at  a  specific  site 
the  ability  to  control  not  only  on-site  resources  but  that  of  shared  resources 
located  at  remote  sites. 

•  Open  Architecture  -  A  system  that  implements  open  specifications  for 
interfaces,  services,  and  supporting  formats  to  enable  properly  engineered 
applications  software:  (a)  to  be  ported  with  minimal  changes  across  a  wide 
range  of  systems,  (b)  to  incorporate  with  other  applications  on  local  and  remote 
systems,  and  (c)  to  interact  with  users  in  a  style  that  facilitates  user  portability. 
The  inherent  benefit  is  that  it  allows  future  developing  systems  to  use  existing 
resources  that  can  be  shared  or  ported  across  an  interconnected  network.  [Ref. 
4] 

•  Plug-In-Use  -  Until  the  establishment  of  a  truly  open  architecture,  Plug-In-Use 
will  provide  individuals  access  to  another’s  resources.  The  advantage  is  a 
lower  total  cost  because  the  development  of  a  simple  black  box  which  allows  a 
system  to  communicate  to  an  initially  non-compatible  resource  is  less 
expensive  then  building  a  dedicated  resource  which  would  be  compatible  to  the 
original  system.  An  example  of  implementing  this  concept  would  be  the 
option  currently  undertaken  by  NAVSOC  that  allows  direct  commanding  of 
satellites  through  the  use  of  the  AFSCN  established  antenna  network. 

•  Operator  System  Interface  -  The  interaction  between  the  operating  system  and 
operator  which  allows  the  operator  the  ability  to  disseminate  the  graphically 
represented  data.  The  tendency  now  is  towards  simplified  icon  oriented  graphic 
representations  of  system  status's  which  allows  for  ease  of  use  while  cutting 
down  on  required  console  training  requirements. 

•  Open  System  Interconnection  (OSI)  -  The  OSI  model  is  the  formulation  of 
protocols  used  for  data  communications.  It  sets  down  a  set  of  rules  governing 
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communications  between  systems  and  defines  the  functional  operation  of  the 
communications  between  user  and  network  elements.  A  current  example  would 
be  the  Space  Communications  Protocol  Standards  (SCPS)  which  incorporates 
the  OSI  model  and  dictates  the  packaging  sequence  for  communication 
between  ground  station  and  SV's.  The  use  of  SCPS  would  prevent  the  future 
development  of  satellites  with  proprietary  conununication  methodology  which 
would  require  additional  expensive  handling  from  current  TT&C  facilities. 
The  resultant  is  reduced  space  operations  costs  and  improved  interoperability. 

The  Decision  maker  needs  to  identify  the  above  mentioned  trends  in  a  proposed 
architecture.  If  the  above  mentoned  trends  are  implemented,  two  criteria  must  be 
determined;  (1)  ensure  that  the  benefit  of  that  trend  is  occurring  and  (2)  recognize  to  what 
degree  this  trend  is  beneficial. 

In  the  following  chapter,  an  assisting  tool  to  the  decision  maker  will  be  provided 
that  will  determine  the  degree  of  benefit  of  an  overall  proposed  architecture.  However,  if 
the  decision  maker  cannot  identify  the  use  of  the  trends,  he  /  she  must  question  the 
proposer  of  the  architecture  to  identify  what  achieves  the  benefits  of  lower  life  cycle  cost, 
manpower  reduction,  simplicity  of  process,  and  potential  for  growth.  Once  this  has  been 
answered  and  using  the  tool  provided  in  Chapter  IV,  the  decision  maker  will  be  able  to 
determine  if  this  is  an  acceptable  risk. 
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IV.  COMPARISON  METHODOLOGY 


A.  INTRODUCTION 

Recall  that  in  Chapter  I,  it  was  stated  that  the  primary  goal  was  to  provide  a 
methodology  capable  of  comparing  current  and  future  TT&C  candidate  architectures.  By 
rating  candidates,  the  attempt  is  to  reduce  O&M  cost,  improve  efficiency  while 
maintaining  mission  effectiveness,  and  solidify  space  vehicle  control  requirements.  To 
accomplish  this,  the  decision  maker  is  specifically  tasked  to  develop  and  apply  a 
structured  methodology  to  allow  scoring  and  ranking  of  candidate  architectures  in  terms 
of  their  operational  merit  and  cost.  It  is  important  to  note  that  operational  merit  is  an 
objective  rating  of  measures  in  both  effectiveness  and  performance  of  individual 
architectures.  Whereas,  cost  will  primarily  deal  with  the  overall  life  cycle  cost.  The 
analytic  hierarchy  process  (AHP)  presents  itself  as  an  ideal  method  in  achieving  this 
primary  goal.  In  addition  to  presenting  the  AHP  process,  the  authors  will  provide  an 
illustrated  example  that  will  execute  the  step  by  step  procedures  to  aid  in  comprehension. 

1.  The  Analytic  Hierarchy  Process 

The  analytic  hierarchy  process  (AHP),  developed  by  Thomas  L.  Saaty,  is  designed 
to  solve  complex  problems  involving  multiple  criteria.  The  process  can  be  divided  into 
the  following  steps: 

•  Develop  a  hierarchy  or  graphical  representation  of  the  problem  in  terms  of  the 
overall  goal,  criteria,  and  the  decision  alternatives. 

•  Develop  a  scaling  methodology  to  enable  an  unweighted  ranking  of  decision 
alternatives  based  on  the  criteria. 

•  Establish  significant  relationships  between  multiple  criteria's  through  a 
pairwise  comparison  methodology. 

•  Calculate  a  final  weighted  ranking  of  the  decision  alternatives. 


61 


•  Develop  a  cost  hierarchy  of  each  decision  alternative. 

The  above  steps  require  the  creation  of  working  groups  capable  of  identifying 
essential  criteria  which  is  quantifiable  and  pertinent  to  the  overall  goal.  Once  a  list  of 
criteria  has  been  established,  the  working  group  must  conduct  two  tasks.  First,  through 
an  established  scaling  method,  the  group  ranks  each  of  the  decision  alternatives  on  each 
of  the  criteria.  Finally,  the  relative  importance  between  each  individual  criteria  must  be 
established.  AHP  recommends  a  pairwise  comparison  method  to  achieve  this.  Once  the 
two  tasks  are  completed,  a  mathematical  procedure,  known  as  synthesization,  is  used  to 
develop  a  weighted  ranking  of  decision  alternatives.  The  last  stage  is  to  provide  a  cost 
hierarchy  of  each  decision  alternative.  This  cost  hierarchy,  along  with  the  weighted 
ranking,  will  provide  the  decision  maker  with  the  decisive  tools  necessary  to  make  an 
informed  decision.  [Ref.  13] 

B.  DEVELOPMENT  OF  AN  EQUAL  WEIGHTED  RANKING 

The  initial  step  in  AHP,  as  outlined  above,  is  to  provide  a  list  of  criteria’s  to 
evaluate  candidate  architectures.  From  Chapters  11  and  III,  it  was  detemuned  that  the 
method  to  achieve  this  would  be  through  identifying  the  primary  performance  /  system 
drivers.  These  drivers  would  be  essential  in  accomplishing  all  functions  regarding 
planning,  operations,  system  networking,  and  analysis.  After  thorough  evaluation,  eleven 
predominant  drivers  were  revealed  as  likely  candidates  for  a  formation  of  a  criteria  list.  It 
is  important  to  note  that  through  further  research  and  analysis,  additional  drivers  may  be 
incorporated  into  this  list.  The  following  section  will  identify  each  individual  system  / 
performance  driver  and  provide  an  associated  scaling  method.  To  rank  a  driver's  ability 
to  accomplish  a  specific  function,  a  scale  with  values  ranging  from  0  to  3  was  developed. 
These  ranging  values  were  associated  with  certain  attributes  capable  of  being  included  in 
the  design  of  a  candidate  architecture.  In  some  cases,  a  driver  will  not  be  presented  with 
a  complete  0  to  3  range  for  scaling  values  because  of  limiting  attributes.  An  example  can 
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be  found  below  when  discussing  the  driver  standardization,  the  number  zero  was  not 
used. 


1.  TT&C  System  /  Performance  Drivers  and  Associated  Scaling 

a.  Capacity 

Capacity  allows  for  the  following:  advanced  capacity  management  planning 
ability;  data  rate  easily  variable  to  25  Mbps  based  on  user  needs;  and  distributed  open 
computing  environments  for  easily  expandable  data  processing  capability.  The  rating 
scale  for  capacity  is: 

•  1  implies  the  architecture  exhibits  only  minimal  growth  capacity:  meets  one 
attribute  or  less 

•  2  implies  the  architecture  exhibits  only  moderate  growth  capacity:  meets  two 
attributes 

•  3  implies  the  architecture  exhibits  a  high  growth  capacity:  meets  all  three 
attributes. 

b.  Flexibility 

Flexibility  is  a  driver  that  takes  into  account  automated  mission  planning  and  or 
scheduling;  easily  expandable  and  reconfigurable  communications  capability;  secure 
system  configurations  to  allow  for  operations  across  all  classification  levels;  and  lastly 
distributed  open  computing  environments  to  allow  rapid  operational  changes.  The  rating 
scale  for  flexibility  is; 

•  1  implies  only  minimally  flexible:  the  architecture  exhibits  less  than 
two  of  the  above  attributes 

•  2  implies  moderately  flexible:  the  architecture  exhibits  two  or  three  of  the 
above  attributes 
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•  3  implies  highly  flexible:  the  architecture  exhibits  three  or  more  of  the  above 
attributes. 

c.  Information  Timeliness 

This  attribute  is  a  measure  of  the  architecture  to  satisfy  all  requirements  levied 
on  the  space  vehicles  control  system  by  the  operational  tasking,  in  a  timely  manner.  The 
rating  scale  for  Information  Timeliness  is: 

•  1  implies  the  architecture  in  question  cannot  satisfy  all  the  requirements  as 
based  in  the  OPLAN  and  user  requirements  documentation 

•  2  implies  the  architecture  in  question  can  satisfy  alLrequirements  . 

d.  Maturity 

Maturity  is  a  measure  of  the  state  of  development  of  the  proposed  architecture. 
If  the  architecture  is  or  has  been  operating  in  a  fully  operational  mode,  then  the  candidate 
may  be  considered  mature.  If  the  candidate  is  based  on  technology  under  development 
and  does  not  currently  exist,  then  the  architecture  is  in  a  conceptual  state  and  cannot  be 
considered  mature.  It  is  understandable  that  there  will  be  some  overlap  between  maturity 
and  technical  risk.  The  rating  scale  for  maturity  is: 

•  1  implies  Conceptual :  greater  than  9  years  to  produce 

•  2  implies  Research:  5  to  9  years  to  produce 

•  3  implies  Development:  0  to  5  years  to  produce 

e.  Relative  Cost 

Relative  cost  is  the  cost  to  research  the  technical  issues,  develop,  test  and  field 
the  proposed  TT&C  architecture.  The  relative  cost  is  not  given  in  terms  of  cost  versus 
effectiveness  of  the  system,  but  use  of  the  other  eleven  drivers  will  result  in  a  higher 
ranking  for  a  more  cost  effective  system.  The  rating  scale  for  relative  cost  is: 
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0  implies  Very  High 


•  1  implies  High 

•  2  implies  Medium 

•  3  implies  Low. 

/.  Reliability 

That  architecture  which  exhibits  the  following:  expandable  high  data  rate 
distributed  workstations  and  broadened  communications  network;  automated  error 
detection  and  correction;  and  no  mission  impacting  single  point  of  failure.  The  rating 
scale  for  Reliability  is: 

•  1  implies  the  architecture  exhibits  only  minimal  reliability  or 
availability:  meets  one  attribute  or  less 

•  2  implies  the  architecture  exhibits  only  moderate  reliability  or 
availability:  meets  two  of  the  attributes 

•  3  implies  the  architecture  exhibits  a  high  reliability  or  availability:  meets  all 
three  attributes. 

g.  Reporting  &  Tasking 

Reporting  and  tasking  takes  into  account  the  following:  distributed  open 
computing  environment  with  interface  to  existing  external  standard  command  and  control 
systems  for  near  real-time  reporting  and  current  status  updates  based  on  operational 
requirements;  and  distributed  open  computing  environment  with  interface  to  external 
standard  command  and  control  system  for  near  real  time  tasking  response  based  on 
operational  requirements.  The  rating  scale  for  Report  and  Tasking  is: 

•  1  implies  the  candidate  architecture  does  not  meet  any  of  the  attributes 
associated  with  reporting  and  tasking 
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•  2  implies  the  candidate  architecture  meets  only  one  of  the  attributes  associated 
with  reporting  and  tasking 

•  3  implies  the  candidate  architecture  meets  all  of  the  attributes  associated  with 
reporting  and  tasking. 

h.  Standardization 

The  standardization  of  a  TT«feC  architecture  looks  at  the  standard  interfaces  for 
all  applications  within  the  system  and  to  all  external  users.  The  attribute  also  takes  into 
account  minimum  need  for  dedicated  resources  or  payload  specific  configurations. 
Finally,  the  driver  takes  into  account  the  standard  communications  protocols  and 
interfaces  for  voice,  data,  and  video. 

The  rating  scale  for  standardization  is; 

•  1  implies  minimal  use  of  standardization:  meets  one  of  the  attributes 

•  2  implies  moderate  use  of  standardization  practices:  meets  two  of  the  attributes 

•  3  implies  a  high  use  of  standardization  practices:  meets  all  three  attributes. 

i.  Survivability 

This  attribute  is  a  measure  of  an  architecture's  capability  of  operating  in  a 
mobile/transportable  environment  in  support  of  warfighting  missions.  The  driver  also 
considers  malicious  attacks  on  the  system  by  either  conventional  or  informational 
methods.  The  rating  for  survivability  is: 

•  1  implies  architecture  cannot  operate  in  a  mobile  /  transportable  environment 

•  2  implies  the  architecture  can  operate  effectively  in  a  mobile  /  transportable 
environment. 
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j.  Technical  Risk 

The  technical  risk  is  determined  by  evaluating  the  current  state  of  technology 
versus  the  technology  necessary  to  employ  a  proposed  candidate  architecture.  The  risk 
involved  is  the  risk  of  developing  the  technology  in  the  time  frame  necessary  to  support 
employment  of  a  new  system.  The  rating  scale  for  technical  risk  is: 

•  1  implies  High:  major  technical  problems  to  resolve 

•  2  implies  Medium:  moderate  technical  problems  to  resolve 

•  3  implies  Low:  only  minor  technical  problems  to  resolve. 

k.  Training 

This  attribute  allows  for  the  direct  connectivity  between  the  space  vehicle 
operations  center  and  the  space  vehicle  control  simulation  systems  (training  facilities). 
The  rating  for  this  attribute  is: 

•  1  implies  no  standardized  interfaces  for  interactive  training  or  direct 
connectivity  between  operations  centers  and  training  centers 

•  2  implies  implementation  of  standardized  interfaces  for  interactive  training  and 
support  for  direct  connectivity  between  operations  centers  and  training  centers. 

2.  Development  of  an  Equal  Weighted  Ranking  Matrix 

The  authors  evaluated  the  AFSCN,  MCC,  and  the  NAVSOC  architectures  using 
the  eleven  system  /  performance  drivers  and  the  rating  scale  presented  in  the  previous 
section.  The  results  are  presented  in  Table  3,  Equal  Weighted  Ranking  of  TT&C 
Architectures.  This  ranking  assumes  that  all  the  performance  drivers  are  of  equal  weight. 
As  a  result  of  completing  Table  3,  NAVSOC  is  revealed  as  the  most  favorable  candidate 
architecture  based  on  its  level  of  performance. 
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TT&C  Drivers 

AFSCN 

MCC 

NAVSOC 

Capacity 

1 

1 

1 

Flexibility 

1 

2 

3 

Information  Timeliness 

2 

2 

2 

Maturity 

3 

3 

3 

Relative  Cost 

3 

2 

2 

Reliability 

1 

3 

2 

Reporting  &  Tasking 

1 

2 

2 

Standardization 

1 

2 

2 

Survivability 

1 

1 

2 

Technical  Risk 

3 

2 

2 

Training 

1 

2 

2 

Unweighted  Score 

18 

22 

23 

Unweighted  Ranking 

3 

2 

1 

Table  3,  Equal  Weighted  Ranking  of  TT&C  Architectures 


C.  RELATIVE  SIGNIFICANCE  OF  SYSTEM  /  PERFORMANCE  DRIVERS 

Since  the  development  of  Table  3  assumed  that  all  weights  were  of  equal 
importance,  the  next  step  would  be  to  determine  how  to  assign  weighting  factors  to  the 
individual  performance  /  system  drivers.  Recall  that  in  Section  A  of  this  chapter,  AHP 
was  indicated  as  the  method  to  achieve  this  task.  While  a  more  complete  description  of 
AHP  can  be  found  in  Reference  13,  Section  A  further  states  the  description  for  this 
process. 

1.  Pairwise  Comparison  of  Drivers 

The  task  of  weighting  the  performance  /  system  drivers  begins  with  identifying  a 
working  group,  consisting  of  a  variety  of  system  experts,  and  an  established  scaling 
criteria.  The  final  result  of  the  working  group  is  a  scaled  driver  relationship  obtained 
through  pairwise  comparison.  This  method  of  comparison  forces  a  subjective  opinion  on 
how  well  one  attribute  stands  against  another.  A  list  of  attributes  can  then  be  prioritized 
from  highest  to  lowest  in  relative  importance. 
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In  an  attempt  to  illustrate  this  procedure,  a  working  group  consisting  of  Naval  Post 
Graduate  School  students  from  the  Space  Systems  Operations  curriculum  was  utilized. 
This  working  group  was  provided  a  survey  questionnaire  which  enabled  them  to  conduct 
a  pairwise  comparison  of  the  eleven  identified  critical  drivers.  A  complete  copy  of  the 
survey  questionnaire  is  provided  in  Appendix  D.  Table  4,  The  Rating  Scale,  was 
provided  to  the  working  group  as  the  agreed  upon  method  of  scaling. 


Scale  Value 

Description 

9 

Extremely  More  Important 

8 

Strongly  More  Important 

7 

Moderately  More  Important 

6 

Slightly  More  Important 

5 

Equally  Important 

4 

Slightly  Less  Important 

3 

Moderately  Less  Important 

2 

Strongly  Less  Important 

1 

Extremely  Less  Important 

Table  4,  The  Rating  Scale 


To  achieve  a  graphical  representation,  a  pairwise  comparison  matrix  based  on  the 
number  of  critical  attributes  is  created.  In  this  illustrated  example,  an  eleven  by  eleven 
matrix  was  developed  which  matches  the  number  of  critical  drivers  identified.  The  axis 
of  this  matrix  list  these  eleven  drivers  and  provides  a  space  to  record  the  value  of  each 
pairwise  comparison  derived  from  the  data  collected  from  the  survey  questionnaire.  The 
results  of  the  working  group  survey  questionnaire  is  presented  in  Table  5,  Relative 
Significance  Of  TT&C  Drivers. 
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Table  5,  Relative  Significance  of  TT&C  Drivers 


2.  Development  of  Normalized  Driver  Relationship  Table 

To  further  aid  in  the  ease  of  presentation  it  is  beneficial  to  normalize  Table  4-3. 
This  is  accomplished  by  summing  the  individual  columns  and  then  dividing  each  entry  in 
the  column  by  the  column  sum.  Table  6,  The  Normalized  Relative  Significance  of 
TT&C  Drivers,  is  the  product  of  this  procedure.  Prior  to  calculating  the  weighted  ranking 
of  candidate  architectures,  the  means  from  each  row  of  the  normalized  table  must  be 
computed.  The  mean  of  each  critical  driver  is  shown  in  its  own  separate  line  at  the 
bottom  of  Table  6. 

After  completing  the  table,  it  revealed  that  the  three  most  important  drivers  were 
Reliability,  Survivability,  and  Information  Timeliness.  Additionally,  it  showed  that  the 
least  favorable  driver  was  Relative  Cost  which  would  indicate  a  tendency  for  it  being  an 
ideal  trade  off  candidate.  These  results  could  be  explained  by  examining  the  actual 
survey  group  utilized  to  produce  the  data.  This  group  consisted  of  active  duty  personnel 
from  varying  armed  force  services.  As  such,  they  are  more  concerned  with  user  driven 
performance  of  a  system  vice  engineers  who  stress  the  technical  impacts  or 
developmental  potential  of  that  system.  The  placement  of  emphasis  on  these  attributes 
will  contribute  to  the  creation  of  a  weighted  ranking  in  the  following  section. 
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Capacity  Flexibility  Information  Maturity  Relative  Cos!  Reliability  Reporting  Standardization  Survivability  Technical  Risk  Training 
Timeliness  4  Tasking 


Table  6,  The  Normalized  Relative  Significance  of  TT&C  Drivers 
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0.1022  0.0776  0.0736  0.111  0.0907  0.084  0.1041  0.0845 


D.  DEVELOPMENT  OF  A  WEIGHTED  RANKING 

The  conclusion  of  this  process  entails  the  development  of  the  weighted  ranking  of 
the  proposed  candidates.  This  becomes  the  essential  decision  tool  that  can  be  graphically 
represented  in  a  table  format  for  the  decision  maker.  This  involves  multiplying  the 
unweighted  ranking  values  of  the  decision  alternatives  with  the  mean  relative  significance 
values  of  individual  criteria's  (i.e.  system  /  performance  drivers).  To  continue  with  the 
illustrated  example,  the  unweighted  values  from  Table  3  and  the  mean  values  located  in 
Table  5  were  computed  as  per  the  above  procedure.  The  result  being  the  formation  of 
weighted  values  which  are  presented  in  Table  7,  The  Weighted  Ranking.  Simply  adding 
the  values  in  each  column  results  in  each  architectures  weighted  score.  The  weighted 
ranking  is  determined  by  numerical  ranking  of  the  individual  scores.  This  means  that  the 
highest  weighting  score  ranks  first,  the  lowest  score  would  rank  last  and  all  others  fall 
somewhere  between. 

The  weighted  ranking  displayed  in  Table  7  shows  the  preferred  candidate 
architecture  to  be  NAVSOC,  followed  by  MCC  and  AFSCN,  respectfully.  This  matches 
the  results  found  in  Table  3  which  were  developed  with  the  equal  weighted  ranking  as  a 
first  approximation.  It  should  be  noted  that  what  has  been  presented  is  an  illustrated 
example.  A  more  diverse  survey  group  could  possibly  achieve  a  different  conclusion. 
Even  with  this  survey  group  the  resulting  value  that  separated  first  and  second  place 
candidates  was  a  mere  0.0856  . 
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TT&C  Drivers 

AFSCN 

MCC 

NAVSOC 

Capacity 

0.0901 

0.0901 

0.0901 

Flexibility 

0.185 

Information  Timeliness 

0.2044 

Maturity 

0.2328 

0.2328 

Relative  Cost 

0.2208 

0.1472 

0.1472 

Reliability 

0.111 

0.333 

0.222 

Reporting  &  Tasking 

0.0907 

0.1814  ^ 

0.1814 

Standardization 

0.084 

0.168 

0.168 

Survivability 

0.1041 

0.1041 

0.2082 

Technical  Risk 

0.2535 

0.169 

0.169 

Training 

0.089 

0.178 

Weighted  Score 

1.5728 

2.0786 

Weighted  Ranking 

3 

2 

1 

Table  7,  Weighted  Ranking  of  TT&C  Architectures 


E.  EVALUATION  OF  THE  COST  HIERARCHY 

The  decision  maker's  ability  to  choose  a  proposed  decision  alternative  is  motivated 
not  only  by  performance  but  cost  concerns.  The  final  stage  in  AHP  instructs  the  decision 
maker  to  weigh  performance  versus  cost  of  each  candidate.  The  previous  sections  gave 
the  decision  maker  the  ability  to  grade  an  architectures  performance.  It  is  essential  to 
understand  that  there  exists  a  cost  for  that  associated  performance  level.  To  aid  in  a  cost 
analysis  of  TT&C  architectures,  a  cost  hierarchy  model  was  developed.  This  model 
stresses  specific  areas  where  significant  cost  is  incurred  within  any  given  architecture. 
Figure  13,  The  Cost  Analysis  Model,  indicates  four  major  areas  determined  by  the 
authors  to  be  essential.  The  majority  of  cost  in  an  architecture  occurs  during  its 
development,  setup  and  production,  and  its  continued  operations  and  maintenance.  It  is 
also  important  to  note  that  unforeseen  cost  will  occur  and  the  model  provides  for  this  in 
an  area  labeled  Uncertainty. 
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•  HAV&SAV  Design 

•  Integration 

•  Test 

•  Prototype 

•  Docnmentation 

•  Training 

^  Support  Equip 


•  Set-up 

•  COTS(HAV,S/W) 

•  Documentation 

•  Test 

•  Installation 


•  Ops  Personnel 

•  Maintenance 

•  Repair 
•Spares 

•  LEO 

•  Facilities 

•  Lease  (Comm) 


•  Development 

•  Production 

•  O&M 


V _ y 

Figure  1 3,  The  Cost  Analysis  Model 


F.  SUMMARY 

The  methodology  presented  in  this  chapter  provides  the  decision  maker  with  an 
objective  approach  to  evaluate  potential  future  as  well  as  current  TT&C  architectures. 
An  illustrated  example  was  provided  with  each  step  to  aid  in  clarification  of  the 
procedures  involved.  The  chapter  also  gave  a  brief  insight  into  the  cost  analysis  model 
associated  with  TT«&:C  environment.  Coupled  with  the  information  contained  in  Chapters 
11  and  in,  a  foundation  has  been  established  which  will  provide  a  substantial  aid  in  any 
future  decisions  concerning  TT&C  architectures. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  SUMMARY 

The  intention  of  the  authors  was  to  focus  the  research  into  a  format  usable  by  a 
decision  maker  to  aid  in  the  selection  of  future  TT&C  architectures.  As  can  be  seen  in 
the  layout  of  the  chapters,  this  was  achieved  through  four  distinct  steps.  These  steps  act 
as  a  capable  aid  by  providing  the  following:  better  understanding  of  the  process  involved 
in  TT&C;  knowledge  of  what  is  available  by  identification  of  current  architectures; 
comprehension  of  developing  trends  which  will  be  seen  in  the  proposed  candidates;  and 
demonstration  of  an  objective  methodology  which  can  be  used  for  evaluation. 

1.  The  TT&C  Process 

In  Chapter  II,  the  first  step  in  aiding  the  decision  maker  was  accomplished  by  a 
descriptive  illustration  of  the  TT&C  process.  A  better  understanding  would  provide  a 
foundation  capable  of  allowing  a  more  informed  decision.  The  authors  were  able  to 
identify  and  illustrate  the  interrelationships  of  primary  and  associated  functions  as  they 
pertain  to  a  generic  TT&C  architecture. 

2.  Current  Architectures 

The  goal  of  the  second  step  was  to  inform  the  decision  maker  of  current  TT&C 
architectures.  Chapter  III  reviewed  three  of  these  architectures:  Air  Force  Satellite 
Control  Network  (AFSCN),  Mission  Control  Center  (MCC),  and  Naval  Satellite 
Operations  Center  (NAVSOC).  The  architectures  chosen  represented  varying  methods  of 
conducting  TT&C. 

3.  Trends  In  TT&C  Architectures 

In  addition.  Chapter  III  highlighted  the  trends  in  TT&C  architecture  development 
based  on  DOD  policies  and  existing  architectures.  This  third  step  would  alert  those 
involved  in  the  evaluation  process  to  what  TT&C  developments  can  be  expected  or 
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required  in  future  proposals.  The  following  trends  were  identified  and  should  be  regarded 
for  future  developing  architectures: 

(1)  automation 

(2)  Commercial  Off  The  Shelf  (COTS) 

(3)  distributed  systems 

(4)  open  architectures 

(5)  plug-in-use 

(6)  graphic  operator  interfaces 

(7)  use  of  the  Open  System  Interconnection  (OSI)  Model 

4.  The  Methodology  and  Illustration 

The  last  step  focused  on  providing  a  method  for  objective  evaluation  of  TT&C 
architectures.  Through  discussions  in  Chapter  IV,  critical  performance  and  system 
drivers  were  identified.  The  Analytic  Hierarchy  Process  (AHP),  an  evaluation  tool,  was 
then  applied.  To  aid  in  the  comprehension  of  how  AHP  appplies,  an  illustrative  example 
was  provided.  The  example  utilized  the  AFSCN,  MCC,  and  the  NAVSOC  architectures 
that  were  described  in  Chapter  III. 

B.  CONCLUSIONS 

The  authors  offer  the  decision  maker  an  alternative  approach  in  evaluating  current 
and  future  TT&C  architectures.  The  benefit  of  their  proposed  methodology  lies  in  its 
ability  to  be  applied  to  architectures  of  varying  design  and  complexity.  Developing 
TT&C  systems  will  take  advantage  of  new  state-of-the-art  technologies.  It  is  this 
technology  evolution  that  the  methodology  specifically  addresses. 
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This  method  is  presented  in  its  most  basic  form.  It  has  the  potential  for  further 
growth.  As  new  drivers  or  trends  are  realized,  it  is  a  simple  process  to  incorporate  them 
and  achieve  meaningful  results.  The  authors  note  that  a  thorough  cost  analysis  of 
candidate  TT&C  architectures  should  be  performed  in  conjunction  with  the  use  of  this 
methodology.  This  would  provide  a  complete  cost  and  operational  effectivness  analysis 
(COEA). 

C.  RECOMMENDATIONS 

The  methodology  presented  in  this  thesis  represents  the  first  prototype  of  an 
objective  tool  for  evaluating  alternative  TT&C  architectures.  It  is  the  authors  opinion  that 
there  exist  multiple  areas  that  could  be  further  expanded.  The  most  obvious  areas  include 
the  following; 

(1)  Further  development  of  the  TT&C  process  model  to  include  additional 
analysis  of  lower  levels  associated  with  sub-functions  already  presented. 

(2)  Development  of  a  thorough  cost  modeling  hierarchy  for  a  generic  TT&C 
architecture. 

(3)  Conduct  additional  surveys  with  technical  experts  as  well  as  other  users 
concerned  with  TT&C  development  for  the  purpose  of  validating  the 
method  proposed  in  this  thesis. 
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TITLE:  Perform  System  Analvsis  NUMBER: 


APPENDIX  B.  DATA  DEFINITIONS 


Alarms:  Pre  -  programmed  indicators  which  detect  adverse  anomalies  that  exceed 
established  space  vehicle  and/or  ground  facility  limitations. 

Available  Assets:  A  list  of  current  status  and  availability  of  resources  allocated  to  the 
TT&C  facility  which  can  be  utilized  for  future  planning. 

Commanding:  This  is  the  uplink  information  required  to  instmct  a  SV  for  the  purpose  of 
controlling  mission  execution  or  maintaining  operability.  This  information  typically 
includes  synchronization  code,  spacecraft  address  bits,  command  message  bits  ,  and  error 
check  bits. 

Computer  Hardware  &  Software:  Advanced  computational  equipment  and  associated 
software  required  to  carry  out  such  activities  as  scheduling,  analysis,  evaluation  and 
system  simulations. 

Constellation  Adjustment:  Requirements,  based  on  current  constellation  coverage, 
used  to  formulate  recommended  actions  to  ensure  maintaining  a  specified  mission 
coverage. 

Contact  Objectives:  Commanding  objectives,  in  order  of  priority,  desired  to  be 
formulated  into  command  code  and  sent  during  establishment  of  communication  lock 
between  SV  and  ground  facility. 

Contact  Status  Summary:  A  descriptive  summary  of  actions  taken  during  a  mission 
contact  phase. 
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Contact  Track:  The  initial  establishment  of  a  lock-on  between  a  space  vehicle 

and  its  ground  facility's  tracking  network. 

Deployment  Plan;  A  generated  order  of  tasking  requirements  for  a  specific  space  force 
deployment.  Included  in  this  plan  would  be  the  following:  support  pre-launch 
preparations,  launch  support,  early  orbit  check  out,  positioning  of  space  assets  on  -  orbit, 
request  for  data,  movement  of  spares,  and  repositioning  for  coverage. 

Detected  Problem:  Identification  of  an  observed  malfunction  or  abnormality  discovered 
in  either  the  SV  and/or  component  of  the  ground  segment. 

Distributed  Mission  Data;  Mission  essential  data  in  the  final  format  desired  by  the 
original  tasking  user. 

Facilities:  Those  structures  that  directly  contribute  supportive  roles  necessary  for 
successful  TT&C.  Examples  range  from  remote  antenna  sites,  training  classrooms, 
administration  buildings  and  maintenance  shops. 

Evaluation  Results:  Specific  outcome  of  an  overall  system  performance  evaluation 
concerning  a  S  V  and  the  supporting  ground  segment. 

Evaluation  /  Status  Reports:  An  external  report  generated  for  dissemination  to  outside 
commands  and  non-DOD  users.  Information  contained  may  include  position  and  current 
status  of  mission  SV  and  their  control  assets. 

Ground  Health  &  Status;  Specific  data  that  is  queried  from  participating  ground 
facilities  that  contribute  in  determining  the  current  Health  and  Status  of  the  ground 
segment. 
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Ground  Performance  Report:  Pertinent  ground  segment  information  which  would  be 
used  in  analysis  of  overall  performance. 

Ground  System  Status:  A  list  of  the  current  states  of  critical  system  components  and 
associated  parameters. 

Identified  Action:  The  corrective  actions  presented  to  an  operator  as  a  recommendation 
in  response  to  a  detected  problem. 

Internal  Reports:  A  series  of  in-house  generated  reports  essential  for  smooth 
operations  within  a  TT&C  facility.  Possible  examples  include:  Capacity  Management 
Report,  which  graphically  represents  current  network  loading  and  utilization  data  and 
compares  it  with  the  theoretical  capacity  modeling,  Ground  Segment  Evaluation  Report, 
and  SV  System  Evaluation  Report. 

Immediate  Recommended  Actions:  These  are  tasks  to  an  operator  to  perform  specified 
routines  to  accomplish  a  necessary  action  or  in  response  to  an  identified  problem.  These 
actions  are  associated  with  time  sensitive  requirements  that  cannot  be  satisfied  through 
the  normal  scheduling  or  schedule  addition  process. 

Logistic  Schedule:  Outlines  the  use  of  supporting  elements  of  a  non  -  flight  essential 
nature  after  receiving  initial  requests  for  specific  material  resources  and  support  to  assist 
in  completion  of  scheduled  maintenance. 

Maintenance  Asset  Status:  Indicator  of  ground  segment  hardware  and  software  status. 
Includes  operator  workstations,  processors,  software,  and  simulators. 
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Mission  Data:  Data  taken  from  the  downlinked  telemetry  stream  which  is  mission 
specific. 

Mission  Need  Statement  (MNS):  SV  specific,  the  MNS  details  qualitative  mission 
objectives  which  the  SV  must  achieve  to  be  useful  to  the  user/warfighter. 

Modified  Schedule:  The  result  of  scheduling  deconflictions  used  in  formulating  a 
schedule  modification. 

Non-immediate  Recommended  Actions:  These  are  tasks  to  an  operator  to  perform 
specified  routines  to  accomplish  a  necessary  action  or  in  response  to  an  identified 
problem.  The  actions  can  be  satisfied  through  the  normal  scheduling  or  schedule 
addition  process. 

Operations  Plan:  The  compilation  of  all  plans  required  to  properly  perform  TT&C. 
Examples  would  include:  Mission  Plan,  Schedule  Plan,  Training  Plan,  and  Maintenance 
Plan. 

Operator  Assignment:  Operator  to  operation  allocation. 

Personnel:  The  human  element  required  to  accomplish  all  aspects  of  executing  and 
supporting  TT&C.  Some  examples  would  be  the  following:  Operators,  training 
instructors,  administrators,  and  technicians. 

Personnel  Qualification  Status:  Represents  current  status  of  operator  qualifications  and 
the  expiration  date  of  each  qualification. 

Pointing  Data:  Information  necessary  to  allow  the  tracking  network  to  gain  proper 
orientation  to  establish  a  reliable  uplink  capability. 
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Positioning  Data:  Current  ephemeris  data  derived  from  the  processed  tracking  data. 
Predicted  Position:  Ephemeris  data  based  on  computations  of  a  future  timeline. 
Recommended  Actions:  These  are  assigned  tasks  to  an  operator  to  perform  specified 
routines  to  accomplish  a  necessary  action  or  in  response  to  an  identified  problem. 
Reconfiguration  Plan:  A  specific  mission  plan  based  on  user  and  SV  requirements  that 
would  initiate  proper  configuration  of  the  SV. 

Resource  Conflguration:  Resources  required  of  the  SV  control  network  in  order  to 
perform  scheduled  missions.  This  would  address  the  Network  Utilization  Schedule  that 
outlines  the  operator  to  operation  tasking  and  network  configuration  assignments.  In 
addition,  all  items  required  to  ensure  a  successful  communication  connectivity  throughout 
the  space  control  network  would  be  involved. 

SV  Health  &  Status:  Specific  data  taken  from  the  downlinked  telemetry  that  pertains  to 
the  current  health  and  status  of  a  SV. 

SV  Performance  Report:  Pertinent  platform  /  payload  information  which  would  be  used 
in  analysis  of  overall  performance. 

SV  System  Status:  A  list  of  the  current  status  of  critical  system  components  and 
associated  parameters.  Specific  data  that  contributes  to  the  determination  of  the  current 
SV  health  and  status. 

Schedule  Modiflcatlon:  An  identification  of  specific  mission  tasking  required  to  be 
incorporated  within  the  scheduling  process. 
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Schedule  Options:  Consist  of  several  schedule  considerations  the  result  of  user  tasking 
and  Non  -  Immediate  Recommended  Actions. 

Space  Policy:  Those  space  specific  political  and  economic  guidelines  set  forth  by  the 
following:  Current  Administration,  Congress,  and  DOD. 

Space  Vehicle  Requirements:  Closely  related  to  the  SV  MNS,  SV  requirements  contain 
succinct,  well-defined,  critical  functional  and  operational  elements. 

Specific  Commands:  Those  commands  necessary  in  accomplishing  the  pre  determined 
contact  objectives,  maintaining  Health  &  Status,  and  orbital  orientation. 

Support  Needs:  Contains  specific  supporting  request  for  items  necessary  in  carrying  out 
the  support  functions  identified  mission  area  such  as  Training,  Maintenance,  Logistics, 
and  Supply. 

Support  Requirement:  Include  the  specific  items  such  as,  packaging,  handling, 
transportation,  depot  /  system  technical  orders,  configuration  control,  and  sparing 
strategies. 

Telemetry  Data:  This  is  the  downlinked  information  received  by  the  processing  center 
which  pertains  to  the  health,  status,  and  mission  performance  of  the  SV .  Mission  related 
data,  which  was  collected  by  the  SV,  is  digitized  and  downlinked  in  conjunction  with  the 
previously  mentioned  information. 

Time  Sync:  For  support  of  attitude  control,  commanding,  and  time  -  tagging.  Time  sync 
may  be  supplied  by  either  computer  maintained  counters  or  hardware  timers. 
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Tracking  Data:  This  is  information  required  to  precisely  determine  a  SV  location  and 
velocity  with  respect  to  the  tracking  facility.  The  data  consists  of  time,  elevation,  azimuth, 
range,  and  range  rate. 

User  Feedback:  The  necessary  connectivity  which  allows  for  the  interface  between  the 
user  /  warfighter  and  the  control  system.  Directly  contributes  to  the  overall  quality 
assurance  of  the  SV  control  system. 

User  Tasking:  A  request  by  the  user  /  warfighter  for  either  time  critical  or  routine 
mission  tasking.  Possible  requests  include  either  Reconfiguration  Request  or  Schedule 
Addition  Request. 
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APPENDIX  C.  MCC  SUPPORTING  ANTENNAS 


1.  C  -  Band  Antennas 


Location 

Description 

AFFTC,  EAFB,  CA 

FPS-16 

Antigua  Island 

FPQ-14 

Ascension  Island 

FPQ-15,  TPQ-18 

Bermuda  island 

FPQ-6 

Cape  Canaveral,  FL 

MPS-39,  FPS-16 

DFRC,  CA 

FPS-16,  FPD-16 

Ft.  Huachuca,  Scott  Peak,  AZ 

FPS-16 

Jonathan  Dickinson,  FL 

FPQ-14 

Kaena  Point,  HI 

FPQ-14 

Kwajelein  Island 

TRADEX,  ALCOR,  ALTAIR,  FPQ-19 

Merrit  Island,  FL 

FPQ-14,  MCB-17 

Mt.  Lemmon,  AZ 

CAPRI 

Patrick  AFB,  FL 

FPQ-14 

Point  Mugu,  CA 

FPS-16,  FPS-16V 

Point  Pillar,  CA 

FPQ-6,  MPS-36 

San  Nicolas  Island 

FPS-16 

Vandenberg  AFB,  CA 

FPS-16,  TPQ-18,  HAIR 

Wallops  Flight  Facility,  VA 

FPQ-6,  FPS-16 

White  Sands,  NM 

FPS-16 

White  Sands,  Stall  Station,  NM 

FPS-16 

White  Sands,  Holloman,  NM 

FPS-16 
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2.  S  -  Band  Antennas 


Location 

Description 

Alamo  Peak,  WSMR,  NM 

7.3M,  AZ-EL 

Atom  Peak,  N  Oscurra  Pk,  NM 

7.3M,  AZ-EL 

Bermuda  Island 

9M,  X-Y,  N-S  9M,  X-Y,  E-W 

Colorado  Springs,  CO 

10M,  AZ-EL 

Diego  Garcia 

10M,  AZ-EL 

Dryden,  DFRC,  CA 

4.3M,  AZ-EL 

Goldstone,  CA 

9M,  X-Y,  N-S  26M,  X-Y,  E-W 

Jonathan  Dickinson,  FL 

85ft,  AZ-EL  50ft,  AX-EL 

Guam 

18M,  AZ-EL 

Keana  Point,  HI 

18M,  AZ-EL 

Madrid,  Spain 

26M,  X-Y,  E-W 

Marritt  Island,  FL 

9M,  X-Y,  N-S 

Mt.  Lemmon,  AZ 

4.3M,  AZ-EL 

New  Boston,  NH 

14M,  AZ-EL 

Oak  Hangar,  UK 

18M,  AZ-EL 

Point  Pillar,  CA 

12M,  AZ-EL 

Ponce  de  Leon  Inlet,  FL 

4M,  AZ-EL 

Seychelles,  lOS 

18M,  AZ-EL 

Tidbinbifla,  Australia 

26M,  X-Y,  E-W 

Vandenberg  AFB,  CA 

10M,  AZ-EL  14M,  AZ-EL 

Wallops,  VA 

9M,  X-Y,  E-W 

3.  Optical  Camera 


Location 

Description 

Maui,  HI 

Camera 

Santa  Yenez  Peak,  CA 

Camera 

Tranquiflon  Peak,  CA 

Camera 
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APPENDIX  D:  SURVEY  QUESTIONNAIRE 


Survey  Questionnaire 


9  8765432  1 

I _ I  I  I _ ^ ^ ^ ^ _ I 

EXTREMELY  STRONGLY  MODERATELY  SLIGHTLY  EQUALLY  SLIGHTLY  MODERATELY  STRONGLY  EXTREMELY 

MORE  more  more  MORE  IMPORTANT  LESS  LESS  LESS  LESS 

IMPORTANT  IMPORTANT  IMPORTANT  IMPORTANT  IMPORTANT  IMPORTANT  IMPORTANT  IMPORTANT 


Standardization  is  _ than  Flexibility. 

_ than  Capacity. 

_ than  Reliability 

_ than  Reporting  &  Tasking 

_ than  Information  Timeliness 

_ than  Training 

_ than  Survivability 

_ than  Relative  Cost 

_ than  Technical  Risk 

_ than  Maturity 


Flexibility  is  _ than  Capacity 

_ than  Reliability 

_  than  Reporting  &  Tasking 

_ than  Information  Timeliness 

_ than  Training 

_  than  Survivability 

_  than  Relative  Cost 

_  than  Technical  Risk 

_ than  Maturity 


Capacity  is  than  Reliability 

_  than  Reporting  &  Tasking 

_ than  Information  Timeliness 

_  than  Training 

_ than  Survivability 

_  than  Relative  Cost 

_  than  Technical  Risk 

_ than  Maturity 
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Survey  Questionnaire 


9 

1 

00- 

7 

1 

CO- 

5 

1 

4 

1  - 

CO- 

2 

_i _ 

EXTREMELY 

MORE 

IMPORTANT 

STRONGLY 

MORE 

IMPORTANT 

MODERATELY 

MORE 

IMPORTANT 

SLIGHTLY 

MORE 

IMPORTANT 

EQUALLY 

IMPORTANT 

SLIGHTLY 

LESS 

IMPORTANT 

MODERATELY 

LESS 

IMPORTANT 

STRONGLY 

LESS 

IMPORTANT 

EXTREMELY 

LESS 

IMPORTANT 

Reliability  is  _ than  Reporting  &  Tasking 

_ than  Information  Timeliness 

_ than  Training 

_ than  Survivability 

_ than  Relative  Cost 

_ than  Technical  Risk 

_ than  Maturity 


Reporting  &  Taskins  is 

_ than  Information  Timeliness 

_ than  Training 

_ than  Survivability 

_ than  Relative  Cost 

_ than  Technical  Risk 

_ than  Maturity 

Information  Timeliness  is 

_  than  Training 

_ than  Survivability 

_ than  Relative  Cost 

_ than  Technical  Risk 

_ than  Maturity 

Trainin2  is 

_ than  Survivability 

_ than  Relative  Cost 

_ than  Technical  Risk 

_ than  Maturity 

Survivability  is 

_ than  Relative  Cost 

_ than  Technical  Risk 

_ than  Maturity 

Relative  Cost  is 

_ than  Technical  Risk 

_ than  Maturity 

Maturity  is 

_ than  Technical  Risk 
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1.  DeHnition  of  Terms 


a.  Capacity 

Capacity  allows  for  the  following:  advanced  capacity  management  planning  ability;  data 
rate  easily  variable  to  25  Mbps  based  on  user  needs;  and  distributed  open  computing 
environments  for  easily  expandable  data  processing  capability. 

b.  Flexibility 

Flexibility  is  a  driver  that  takes  into  account  automated  mission  planning  and  or 
scheduling;  easily  expandable  and  reconfigurable  communications  capability;  secure  system 
configurations  to  allow  for  operations  across  all  classification  levels;  and  lastly  distributed  open 
computing  environments  to  allow  rapid  operational  changes. 

c.  Information  Timeliness 

This  driver  is  a  measure  of  the  architectures  ability  to  satisfy  all  requirements  levied  on 
the  space  vehicle's  control  system  by  operational  tasking  in  a  timely  manner. 

d.  Maturity 

Maturity  is  a  measure  of  the  state  of  development  of  the  proposed  architecture.  If  the 
architecture  is  or  has  been  operating  in  a  fully  operational  mode  then  the  candidate  may  be 
considered  mature.  If  the  candidate  is  based  on  technology  under  development  and  does  not 
currently  exist,  then  the  architecture  is  in  a  concept  state  and  cannot  be  considered  mature. 

e.  Relative  Cost 

Relative  cost  is  the  cost  to  research  the  technical  issues,  develop,  test  and  field  the 
proposed  TT&C  architecture. 

/.  Reliability 

That  architecture  which  exhibits  the  following:  expandable  high  data  rate  distributed 
workstations  and  broadened  communications  network;  automated  error  detection  and  correction; 
and  no  mission  impacting  single  point  of  failure. 
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g.  Reporting  &  Tasking 

Reporting  and  tasking  takes  into  account  the  following:  distributed  open  computing 
environment  with  interface  to  existing  external  standard  command  and  control  systems  for  near 
real-time  reporting  and  current  status  updates  based  on  operational  requirements;  and  distributed 
open  computing  environment  with  interface  to  external  standard  command  and  control  system 
for  near  real  time  tasking  response  based  on  operational  requirements. 

h.  Standardization 

The  standardization  of  a  TT&C  architecture  looks  at  the  standard  interfaces  for  all 
applications  within  the  system  and  to  all  external  users.  The  driver  also  takes  into  account 
minimum  need  for  dedicated  resources  or  payload  specific  configurations.  Finally  the  driver 
takes  into  account  for  standard  communications  protocols  and  interfaces  for  voice,  data,  and 
video. 


i.  Survivability 

This  driver  is  a  measure  of  an  architectures  capability  to  operate  in  a  mobile  and  or 
transportable  environment  in  support  of  warfighting  missions.  The  driver  also  considers 
malicious  attacks  on  the  system  by  either  conventional  or  informational  methods. 

j.  Technical  Risk 

The  technical  risk  is  determined  by  evaluating  the  current  state  of  technology  versus  the 
technology  necessary  to  employ  a  proposed  candidate  architecture.  The  risk  involved  is  the  risk 
of  developing  the  technology  in  the  time  frame  necessary  to  support  the  employment  of  a  new 
system. 


k.  Training 

This  driver  allows  for  the  direct  connectivity  between  the  space  vehicle  operations 
center  and  the  space  vehicle  control  simulation  systems  (training  facilities). 
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